Systems and methods for adding functionality to a uis for use at a point of interaction

ABSTRACT

Systems and methods for the addition of functionality to a user identification string (UIS) at a point of interaction (POI) are provided. A UIS is first requested from the user at a POI. According to some embodiments, the user enters a modified UIS (MUIS) at the POI. The MUIS can include a UIS along with a user code. An authorization request is then created by the POI device, wherein the request can include information such as, but not limited to, a vehicle code, the MUIS, POI location identifier, function deduction amounts, and/or the like. An action (e.g. rounding sweep, linking a function to the user operation vehicle, etc.) associated with the user code, if present, is determined and implemented. An approval or denial of the authorization request is then sent to the POI device after the action has been applied and the request has been processed.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No.61/147,011, filed on Jan. 23, 2009 and U.S. Provisional Application No.61/151,480, filed on Feb. 10, 2009, both of which are herebyincorporated by reference in their entirety for all purposes.

This application is also related to the United States patent applicationentitled “Systems and Methods for User Identification String Generationfor Selection of a Function,” with application Ser. No. ______ (AttorneyDocket Number: 79964-368732), filed on the same day as the presentapplication, which is hereby incorporated by reference in its entiretyfor all purposes.

COPYRIGHT NOTICE

Contained herein is material that is subject to copyright protection.The copyright owner has no objection to the facsimile reproduction ofthe patent disclosure by any person as it appears in the Patent andTrademark Office patent files or records, but otherwise reserves allrights to the copyright whatsoever. Copyright© 2009 HSBC Private LabelCorporation

TECHNICAL FIELD

Some embodiments of the present invention generally relate tomulti-function user operation vehicles. More specifically, someembodiments of the present invention relate to systems and methods foradding functionality to a user identification string (UIS) for use at apoint of interaction (POI).

BACKGROUND

There are a variety of payment functions currently in common use.Examples include credit, debit, and prepaid. Historically, one paymentfunction or account was associated with each card or device.Consequently, when a consumer desired to purchase an item using aparticular account, the consumer was required to present the appropriatepayment device to the POI system. For example, when a consumer is buyinggroceries with a debit card, the user would have to present the debitcard. Similarly, when the consumer is shopping at a department storewith a credit card, the consumer would have to present the credit card.In addition, many point of sale devices require, before completion ofthe transaction, the input of a user identification string that is usedto identify the user and indicates that he or she is authorized topurchase items using the payment device.

Traditional infrastructure typically requires that any coupons, rewards,credits, or benefits to be entered or scanned by the cashier. As such,there are a number of challenges and inefficiencies created bytraditional infrastructure for processing payments with rewards. Forexample, transactions with rewards through point of sale (PoS) systemsrequire on-site processing systems.

SUMMARY

Systems and methods are described for adding functionality to a useridentification string (UIS) used with a user operation vehicle at apoint of interaction. In some embodiments of the present invention,reward actions (or other actions) can be initiated by enteringadditional input characters (hereinafter, “user code”) in conjunctionwith the user entering a UIS at a point of interaction device. The pointof interaction device creates an authorization request with informationrelated to the details of the deduction request and the input stringentered by the user. According to some embodiments, the authorizationrequest includes a modified user identification string (MUIS) entered bythe user at the point of interaction device. In some embodiments, theMUIS contains at least a user identification string (UIS) and a usercode (e.g., a reward code, account activation code, and/or other codes).The authorization request, including the MUIS, can contain otherinformation such as, but not limited to, time of purchase, purchaseamount, merchant identification codes, payment function selector, andthe like.

In some embodiments, the authorization request for the completion of apurchase at a point of interaction device is then transferred to aprocessing system. The MUIS can be identified and parsed into the UISand the user code (e.g., a reward code, a function indicator, and/or anaccount activation code) entered by the user at the point of interactiondevice. The user can then be validated (e.g., by a verifier). In someembodiments, the verifier validates the user by comparing a useroperation vehicle UIS stored in a UIS database with the UIS received inthe authorization request. A user code processing system (user codeprocessor) can be used, in accordance with some embodiments, todetermine one or more actions associated with the user code. Once theone or more actions are determined, the user code processing system canimplement the one or more actions before routing the authorizationrequest to one or more function processors for payment authorization.Some examples of actions associated with the user codes include, but arenot limited to, percentage discounts, crediting reward points, accountactivation, linking accounts to the user operation vehicle, and others.

While multiple embodiments are disclosed, still other embodiments of thepresent invention will become apparent to those skilled in the art fromthe following detailed description, which shows and describesillustrative embodiments of the invention. As will be realized, theinvention is capable of modifications in various aspects, all withoutdeparting from the scope of the present invention. Accordingly, thedrawings and detailed description are to be regarded as illustrative innature and not restrictive.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the present invention will be described and explainedthrough the use of the accompanying drawings in which:

FIG. 1 illustrates an example of an activation environment in which someembodiments of the present invention may be utilized;

FIG. 2 illustrates an example of a user identification string (UIS)generation system with various components that can be used in accordancewith some embodiments of the present invention;

FIGS. 3A-3C illustrate examples of screenshots for a user operationvehicle activation interface that may be used in accordance with someembodiments of the present invention;

FIG. 4 illustrates an example of a webpage that might include a Java™applet for collecting a base UIS from a user along with a hyperlink inaccordance with some embodiments of the present invention;

FIGS. 5A-5C illustrate examples of webpages that can convey the selectedbase UIS to the user without actually displaying the UIS on the webpagein accordance with some embodiments of the present invention;

FIG. 6 is a block diagram illustrating components of an activationportal that may be used in accordance with some embodiments of thepresent invention;

FIG. 7 is a block diagram illustrating components of a UIS generationsystem that may be used in accordance with some embodiments of thepresent invention;

FIG. 8 is a flowchart illustrating an example of a method for operationof an activation portal in accordance with some embodiments of thepresent invention;

FIG. 9 is a flowchart illustrating an exemplary set of UIS generationlogic for generating multiple user identification strings in accordancewith some embodiments of the present invention;

FIG. 10 illustrates an example of online transaction processing whichmay be used in some embodiments of the present invention;

FIG. 11 illustrates an example of an operating environment in which someembodiments of the present invention may be utilized;

FIG. 12 is a block diagram illustrating components of a point ofinteraction device that may be used in accordance with some embodimentsof the present invention;

FIG. 13 is a block diagram illustrating components of a verificationsystem that may be used in accordance with some embodiments of thepresent invention;

FIG. 14 is a block diagram illustrating various components that may be apart of a real-time payment processing network in accordance with someembodiments of the present invention;

FIG. 15 is a block diagram illustrating various components that may be apart of a batch payment processing network in accordance with someembodiments of the present invention;

FIG. 16 is a block diagram illustrating various components that may be apart of a parsing and authentication module in accordance with someembodiments of the present invention;

FIG. 17 is a block diagram illustrating various components that may be apart of a reward verification module in accordance with some embodimentsof the present invention;

FIG. 18 is a flowchart illustrating operations for processing atransaction in accordance with some embodiments of the presentinvention;

FIG. 19 is a block diagram illustrating various components that may be apart of an accumulated value function processing system in accordancewith some embodiments of the present invention;

FIG. 20 is an example of a promotional flyer that may be used in someembodiments of the present invention; and

FIG. 21 illustrates an example of a computer system with which someembodiments of the present invention may be utilized.

The drawings have not necessarily been drawn to scale. For example, thedimensions of some of the elements in the figures may be expanded orreduced to help improve the understanding of the embodiments of thepresent invention. Similarly, some components and/or operations may beseparated into different blocks or combined into a single block for thepurposes of discussion of some of the embodiments of the presentinvention. Moreover, while the invention is amenable to variousmodifications and alternative forms, specific embodiments have beenshown by way of example in the drawings and are described in detailbelow. The intention, however, is not to limit the invention to theparticular embodiments described. On the contrary, the invention isintended to cover all modifications, equivalents, and alternativesfalling within the scope of the invention as defined by the appendedclaims.

DETAILED DESCRIPTION

Some embodiments of the present invention generally relate tomulti-function user operation vehicles. More specifically, someembodiments of the present invention relate to systems and methods forthe generation of user identification strings used with multi-functionoperation vehicles and to the addition of functionality to a useridentification string for use at a point of interaction (POI) (e.g., apoint of sale, computer-based interface such as a webpage, computerintegrated system, telephone payment system, or others).

Various systems and methods are described for generating multiple useridentification strings (UIS) for use with a multi-function useroperation vehicle. In some embodiments, a user operation vehicleactivation system monitors for a set UIS request or a change UISrequest. When a request to set or change the UIS is detected, aninterface portal is generated that allows a user to enter a new baseUIS. The interface portal can be designed to allow for entry of anystring of alphanumeric characters that meet preset parameters. Forexample, in some embodiments, the preset parameters could require thebase UIS entered by the user to be a four digit numerical code (e.g.,2319). According to some embodiments, the UIS portal can be a webpage, aJava™ application, a downloadable computer program, and/or the like.Once a base UIS is received, the base UIS can be encrypted andtransferred to a UIS generation system which can be part of the useractivation system in some embodiments.

After the encrypted UIS is received at the user operation vehicleactivation system, the encrypted UIS is decrypted and a determinationcan be made about which accounts and promotions are to be linked to theuser operation vehicle. Various methods can be used for determining theaccounts to be linked to the user operation vehicle. For example, insome embodiments, the determination can be made by searching an accountdatabase for accounts that can be linked with the received useroperation vehicle identification information. Every account found can belinked automatically or a user can select which accounts should belinked through an account user interface screen that is displayed.

In some embodiments of the present invention, the account user interfacescreen is displayed through the interface portal and includes a list ofthe accounts found in the account database that can be linked with theuser operation vehicle. In some embodiments, the screen allows for theuser to enter additional account information (e.g., from other financialinstitutions) for accounts that were not found in the account databaseand that the user desires to be linked to the user operation vehicle.

Once the determination or selection is made about which accounts are tobe linked to the user operation vehicle, the results are transferred toa UIS generation module where an account-specific UIS is generated foreach account linked to the user operation. In accordance with someembodiments of the present invention, the account-specific UIS generatedfor each account is unique and can be generated in a variety of ways(e.g., by appending one or more additional numbers or characters to thefirst UIS for each account linked to the user operation vehicle). As asimple example, suppose a user entered a base UIS of 4719 for a useroperation vehicle with an associated credit function, debit function,and accumulated value function. The UIS generation module could generatean account-specific UIS of 47191 for the credit function, 47192 for thedebit function, and 47193 for the accumulated value function.

One advantage of some embodiments of the present invention is that auser does not have to enter more than one UIS because the systemautomatically creates a unique UIS for each linked account. Then,according to some embodiments, these account-specific UIS's can be usedat a POI (e.g., PoS) device during a transaction (e.g., a purchase) torequest which payment function(s) and/or account(s) associated with theuser operation vehicle should be used.

Some embodiments of the present invention provide for systems andmethods that add functionality to a user identification string for useat a POI. Accordingly, in those embodiments, a user can append a usercode of additional characters (e.g., numbers, letters, specialcharacters, and the like), to the end of the UIS at a POI device tocreate a modified user identification string. In some embodiments, theseadditional characters only include numbers. Whether the additionalcharacters in the user code are just numbers or include some combinationof numbers, letters, and/or special characters, the additionalcharacters can be used to add functionality to the UIS at a POI. Forexample, in some embodiments, the additional characters could be areward code.

The POI device takes the available information and creates a string ofcharacters referred to as a transaction request that includes variouspieces of information about the transaction such as, but not limited to,a user operation vehicle identifier or vehicle code (e.g., a primaryaccount number), a user identification string (UIS), a functionindicator, a reward code, merchant code, payment amount (functiondeduction amount), and/or the like. The string of characters is thentransmitted to a verification network in accordance with someembodiments of the present invention. In some embodiments, the string ofcharacters is then parsed into various tokens (e.g., pieces ofinformation such as the user operation vehicle identifier, the UIS, thefunction selector, and/or the reward code) for processing.

According to some embodiments, the user can be validated using one ormore of the various tokens. For example, the validation in someembodiments of the present invention can occur by comparing a UIS storedin a UIS database that is associated with the primary account numberwith the UIS received in the string of characters. Similarly, adetermination of a reward action associated with the reward code can bemade. The determination of the reward action can occur in a number ofdifferent ways according to various embodiments of the presentinvention. For example, in some embodiments, the reward determinationcan be performed by looking up the reward code in a reward codedatabase. As another example, the reward determination can be performedby deciphering the reward code into various tokens that correspond tovarious reward elements and/or payment types. In some embodiments of thepresent invention a reward code processing system (reward codeprocessor) can be used to determine one or more reward actions andvalidate and/or authorize the reward code.

In some embodiments, once the reward code is determined and applied, apayment request (function deduction request) can then be sent forprocessing. In some embodiments, the payment processing (functiondeduction processing) occurs through a function indicated by a functionindicator included in the string of characters. For example, the paymentprocessing can occur through a rewards processing system, a debitprocessing system, a credit processing system, a prepaid processingsystem, and/or the like.

In the following description, for the purposes of explanation, numerousspecific details are set forth in order to provide a thoroughunderstanding of embodiments of the present invention. It will beapparent, however, to one skilled in the art that embodiments of thepresent invention may be practiced without some of these specificdetails.

Some embodiments of the present invention may be provided as a computerprogram product which may include a machine-readable medium havingstored thereon instructions which may be used to program a computer (orother electronic devices) to perform a process. The machine-readablemedium may include, but is not limited to, floppy diskettes, opticaldisks, compact disc read-only memories (CD-ROMs), and magneto-opticaldisks, ROMs, random access memories (RAMs), erasable programmableread-only memories (EPROMs), electrically erasable programmableread-only memories (EEPROMs), magnetic or optical cards, flash memory,or other type of media/machine-readable medium suitable for storingelectronic instructions. Moreover, embodiments of the present inventionmay also be downloaded as a computer program product, wherein theprogram may be transferred from a remote computer to a requestingcomputer by way of data embodied in a carrier wave or other propagationmedium via a communication link (e.g., a modem or network connection).

While, for convenience, embodiments of the present invention aredescribed with reference to user operation vehicles and UIS, embodimentsof the present invention are equally applicable to various other areaswhere processing orders, rewards, selection of payment options, andselection of service options (e.g., purchase of insurance) may bebeneficial. As just one example, instead of generating multiple useridentification strings, the system could be used to generate multiplecard security codes (i.e., the three or four digit number on the back ofa payment device). As such, the security codes could be used for paymentfunction selection.

For the sake of illustration, various embodiments of the presentinvention have herein been described in the context of computerprograms, physical components, and logical interactions within moderncomputer networks. Importantly, while these embodiments describe variousaspects of the invention in relation to modern computer networks andprograms, the method and apparatus described herein are equallyapplicable to other systems, devices, and networks as one skilled in theart will appreciate. As such, the illustrated applications of theembodiments of the present invention are not meant to be limiting, butinstead exemplary. Other systems, devices, and networks to whichembodiments of the present invention are applicable include, but are notlimited to, other types of systems and processing devices.

TERMINOLOGY

Brief definitions of terms, abbreviations, and phrases used throughoutthis application are given below.

An “accumulated value function” generally describes a payment functionthat enables a merchant and/or other third party system to track and/orreward specific consumer purchases and/or purchase behavior. Forexample, rewards can be generated when a product or item is purchasedwithin a certain category code such as merchant, merchant category,product category, etc. The rewards generated by the consumer purchasesand/or purchase behavior allow the consumer to spend the accrued rewardamounts at a POI. In some embodiments, the accumulated value functionmay receive rewards from one or more systems and apply the rewards to anaccount associated with the accumulated value function. According tosome embodiments, the accrued reward can be, for example, a point-typesystem or cash equivalent that can be used by the consumer at the POIthrough the use of the accumulated value function.

The terms “connected” or “coupled” and related terms are used in anoperational sense and are not necessarily limited to a direct physicalconnection or coupling. Thus, for example, two devices may be coupleddirectly, or via one or more intermediary media, modules, or devices. Asanother example, devices may be coupled in such a way that informationcan be passed therebetween, while not sharing any physical connectionwith one another. Based on the disclosure provided herein, one ofordinary skill in the art will appreciate a variety of ways in whichconnection or coupling exists in accordance with the aforementioneddefinition.

The phrase “in communication with” generally refers to direct andindirect communications for the exchange of information between two ormore devices, modules, applications, systems, components, or the like.For example, two devices may be in communication with each other in sucha way that information or access to the devices can be passedtherebetween, while not sharing any direct physical connection.

The phrases “in some embodiments,” “according to some embodiments,” “inthe embodiments shown,” “in other embodiments,” and the like generallymean the particular feature, structure, or characteristic following thephrase is included in at least one embodiment of the present invention,and may be included in more than one embodiment of the presentinvention. In addition, such phrases do not necessarily refer to thesame embodiments or different embodiments.

If the specification states a component or feature “may”, “can”,“could”, or “might” be included or have a characteristic, thatparticular component or feature is not required to be included or havethe characteristic.

The term “module” refers broadly to software, hardware, or firmware (orany combination thereof) components. Modules are typically functionalcomponents that can generate useful data or other output using specifiedinput(s). A module may or may not be self-contained. An applicationprogram (also called an “application”) may include one or more modules,or a module can include one or more application programs.

The phrase “user operation vehicle” generally refers to any device,biometric identifier, or method for conveying information that may beused to conduct a transaction. Examples of user operation vehiclesinclude, but are not limited to, a plastic card with a magnetic strip, asmart card storing information in onboard memory, a card containing onlyan identifier and linked with a remote database, a card with radiofrequency identification (RFID) technology, a fingerprint, a retinapattern, a voice pattern, or any other physical feature that isdistinguishable between individuals. In some embodiments, a useroperation vehicle could also be any other information such as amemorized code without a corresponding card or device to store ortransfer that code.

General Description

FIG. 1 illustrates an example of an activation environment 100 in whichsome embodiments of the present invention may be utilized. Themulti-function user operation vehicle can be any device, biometricidentifier, or method for conveying information that may be used toconduct a transaction. The multi-function user operation vehicle canpotentially be associated and/or linked with one or more creditfunctions, debit functions, accumulated value functions,consumer-to-consumer payment functions, reward functions, and/or othertypes of payment functions. Examples of other types of payment functionsinclude, but are not limited to, loans (e.g., funds from student loans,bank loans, etc.), flexible spending accounts for healthcare payments,payroll from an employer, reimbursements from an employer, petty cashfrom an employer, corporate incentives, and payments from insurancecompanies (e.g., automobile, health, pet, etc.).

The user operation vehicle in some embodiments of the present inventionincludes a user operation vehicle identifier (vehicle code) that is usedto identify the user operation vehicle and can be used to determinewhich functions are associated and/or linked to the user operationvehicle. One example of a user operation vehicle identifier is a primaryaccount number. In some embodiments, the user operation vehicleidentifiers can be the user operation vehicle itself or separateadditional identifiers. Examples include, but are not limited to RFIDsignatures, a fingerprint of an authorized user, a retina pattern of anauthorized user, a voice pattern of an authorized user, and physicalidentifiers.

A user operation vehicle may be issued to a user after opening one ormore accounts with a financial institution or merchant and requesting auser operation vehicle to link multiple open accounts that are with oneor more financial institutions, merchants, insurance carriers,employers, etc. For example, in some embodiments, a user may be issued auser operation vehicle after applying for and being granted a loan. Theuser operation vehicle would be linked automatically to the loan amount,allowing the user to access the funds through the user operationvehicle. As another example, a gift card ordering service may be used toassociate a prepaid gift card with the user operation vehicle.

The user operation vehicle may or may not be activated initially. Inaddition, the user operation vehicle may or may not be initiallyassociated and/or initially linked with any payment functions. Toactivate the user operation vehicle, associate payment functions, and/orlink payment functions, user 105 can use an activation portal 110. Theuser can be directed to activation portal 110 through informationalcommunications such as flyers, e-mails, telephone calls, or othercommunications that tell the user how to access the activation port 110.According to some embodiments, the informational communications cancontain webpage addresses, telephone numbers, e-mail addresses, postaladdresses, and the like that can be used for activating the useroperation vehicle.

In accordance with some embodiments, activation portal 110 provides aninterface through network 115 to activation system 120 to activate theuser operation vehicles. Activation portal 110 can be any type ofinterface that facilitates the exchange of information required byactivation system 120 for user operation vehicle activation. In someembodiments, activation portal 110 can be, but is not limited to, atelephone, a computer, a computer program, a webpage, a Java™application, and/or the like. Examples of the types of information usedfor user operation vehicle activation in some embodiments of the presentinvention include items such as user identification information, UISentry and/or selection, entry and/or selection of accounts to be linkedto the user operation vehicle, and/or other information as will beappreciated by those of ordinary skill in the art.

Once the requested information is collected from the user throughactivation portal 110, the information is transferred across network 115to activation system 120. Network 115 can be any group of interconnecteddevices capable of exchanging information. In some embodiments, network115 may be as few as several personal computers on a Local Area Network(LAN) or as large as the Internet. Network 115 may also be a Voice overInternet Protocol (VoIP) network or a Voice Response Unit (VRU)according to some embodiments of the present invention. In some cases,network 115 may be comprised of multiple networks (private and/orpublic), even multiple heterogeneous networks, such as one or moreborder networks, voice networks, broadband networks, service providernetworks, Internet Service Provider (ISP) networks, and/or PublicSwitched Telephone Networks (PSTNs), interconnected via gatewaysoperable to facilitate communications between and among the variousnetworks.

Activation system 120 can include, or be in communication with, variouscomponents such as a user verification system, a UIS generation system,a payment verification system, an account verification system, variousdatabases for storing generated UIS, and/or the like. According to someembodiments, a user verification system can be used to verify usercredentials or identification information (e.g., user name and password,voice authentication, calling from a known phone number, etc.) beforeaccess is allowed to activation system 120. Once access is granted,activation system 120 can use a UIS generation system to generate a UISfor each linked account, an account verification system to verify whichaccounts can be linked to the user operation vehicle, and/or a paymentverification system with various databases to store generated UIS andaccount information. In addition, in some embodiments, a linkagegenerator can be used to link accounts/functions to the user operationvehicle. In accordance with some embodiments, the UIS can be any stringof alphanumeric characters including, but not limited to, numbers,letters, special characters, etc. that can be used to identify and/orauthorize the user of a user operation vehicle. For example, the UIS canbe a personal identification number (PIN). In some embodiments, the UISmay indicate which function is being used to complete the transaction, areward to be used, or other feature.

According to some embodiments, activation system 120 monitors for a setUIS request or a change UIS request from user 105. The set or changerequest can come through activation portal 110 via network 115. When arequest to set or change the UIS is detected in some embodiments, anactivation portal response is generated that allows a user to enter anew base UIS or choose a system selected UIS. The activation portalresponse can be designed to allow for entry of any string ofalphanumeric characters that meet preset parameters. For example, insome embodiments, the activation portal response includes the display ofa webpage where the preset parameters are set so that the base UISentered by the user should be a four digit numerical code (e.g., 2319).

FIG. 2 illustrates an example of a user identification string (UIS)generation environment 200 with various components that can be used inaccordance with some embodiments of the present invention. One or moreactivation portals 110 a-110 n can use set UIS interface/applets 210a-210 n for the entry of a new base UIS. According to some embodiments,set UIS interface/applet 210 can be displayed in response to a set orchange UIS request. The set UIS interface/applet can be a webpage, apart of a webpage, a Java™ application, a downloadable computer program,a computer application, and/or the like.

Once a base UIS is received from a user via activation portal 110, thebase UIS can then be encrypted by an encryption/decryption module(encryptor or decryptor) associated with activation portal 110. In someembodiments, the encrypted UIS is transferred to account verificationsystem 220 where a determination can be made as to which accounts can beassociated and/or linked to the user operation vehicle. Examples of thetypes of accounts that can be associated and/or linked to the useroperation vehicle include, but are not limited to, credit accounts,debit accounts, prepaid accounts, accumulated value accounts, storevalue accounts, consumer-to-consumer payment accounts, reward accounts,and/or other types of accounts.

In some embodiments, verification system 220 can identify originationinformation (e.g., IP address, user token, etc.). The originationinformation identified by verification system 220 can be used in someembodiments for tracking marketing penetration by channel (e.g.,webpage, web address, phone calls, etc.).

In some cases, verification system 220 causes an account user interfacescreen to be displayed through the activation portal 110. In otherembodiments, the account user interface screen is part of set UISinterface/applet 210. In either case, the account user interface screenis capable of receiving information from the user about one or moreaccounts the user desires to be associated with the user operationvehicle. In some cases, one or more sets of account information can beautomatically populated from information the user supplied on anapplication or with information about other accounts that are alreadyavailable. Examples of the types of information that can be requestedfrom the user include, but are not limited to, account numbers, firstname, last name, e-mail address, user operation vehicle identificationnumber (if applicable), birthdays, government identification (e.g.,driver's license, social security number, etc.), mother's maiden name,billing addresses, answers to security questions, user IDs, passwordsand/or the like.

Once the desired account information is received, the information can betransferred to verification module (verifier) 220 where the accountinformation entered by the user can be verified. If the account passesthe verification process, then the account information is transferred toUIS generation module 240 where UIS generation module 250 generates anaccount (i.e., account-specific) UIS for each verified account or for asubset of the verified accounts. As one example, UIS generation module250 can generate the account-specific UIS by appending one or moreadditional numbers after the base UIS entered by the user. Theaccount-specific UIS for each verified account can then be stored in UISdatabase 230 for verification during transaction processing (e.g.,processing an authorization request). In some embodiments, between fiveand twenty account-specific UIS's can be generated. In otherembodiments, fewer than five or more than twenty account-specific UIS'scan be generated.

Some embodiments provide for the generation of a completion screen fordisplay through activation portal 110 once the account-specific UISgeneration is completed. The completion screen can provide an indicationto the user that the automatic generation of the account-specific UISfor each account (or payment function) linked to the user operationvehicle is complete. In some embodiments, the completion screen candisplay a list of the account-specific UIS's generated for each account.The completion screen, in some embodiments, can include a graphical userinterface that allows the user to associate an account-specific UIS forone account with another account.

In some embodiments, the account or the account-specific UIS generatedfor each account can be associated with signature default and/or a setorder of precedence to be used for transactions received from the POI.For example, if the user uses the multifunction user operation vehiclewithout entering a UIS for the selection of a particular function (e.g.,a signature-based authorization), then the user can select which of themultiple accounts (e.g., the second credit account) will automaticallyor implicitly be used. The user may continue to assign a prioritizationto each account (or a default sequence of account use) in the event anaccount with a higher priority has insufficient funds or is otherwisenot able to complete the transaction individually (e.g., a maximumtransaction amount has been reached).

In some embodiments, the user may also assign an individual transactionlimit below a system threshold for one or more user operation vehiclefunctions. For example, suppose the user set an order of precedence inthe following order: accumulated value, debit, and then line of credit.Further suppose that the user had a current accrued value of twentythree dollars, a system threshold debit limit of three hundred dollars,and a system threshold credit limit of five hundred dollars. The usermay decide to set a limit (e.g., one hundred fifty dollar limit) for thedebit line in the event that the accumulated value function hasinsufficient accrued value. Now, suppose the user makes a two hundredfifty dollar transaction. Twenty three dollars will be charged to theaccumulated value function, one hundred and fifty to the debit function,and then the final seventy seven dollars to the credit function. Asanother example, instead of making a two hundred fifty dollartransaction, suppose the user made a forty dollar transaction. Then,twenty three dollars will be charged to the accumulated value function,seventeen dollars to the debit function, and nothing to the creditfunction.

As a further example of the generation, viewing and prioritization ofaccount-specific UIS's, suppose a user entered a base UIS of 3892. Anaccount-specific UIS could then be created as 38921 for a first debitfunction, 389212 for a second debit function, 38922 for a creditfunction, 38923 for a first store value function, and 389232 for asecond store value function. In some embodiments, no payment function isimplicit and no initial priority is associated with the paymentfunctions. In some embodiments, an initial prioritization and implicitpayment function (e.g., for signature based authorization) will beautomatically assigned based on a set of assignment rules.

The user could then view the account-specific UIS assigned to eachaccount along with the account prioritization information on thecompletion screen. If desired, the user could then reassociate theaccount-specific UIS for the credit function (i.e., 38922) with thefirst account to be implicitly used during a transaction and the firstdebit account account-specific UIS (i.e., 38921) with the nextfunctional account to be used for a transaction requiring access tomultiple accounts in order to fully complete the transaction. Similarly,for example, the user may reassociate the second debit function UIS(i.e., 389212) with the first debit function and the second store valuefunction UIS with the first store value account, and thus change theorder of account access precedence.

In some embodiments, the graphical user interface can allow the user toassociate the account-specific UIS generated for one account withanother account without changing the set order of precedence of accountusage during a transaction. Similarly, some embodiments allow the userto change the set order of precedence to be used for transactionsreceived from the POI without changing the account-specific UISassociated with the accounts.

The user, in some embodiments of the present invention, may select andsetup one or more special features using the graphical user interface.For example, in addition to setting a base UIS, activating the useroperation vehicle, setting account order precedence, setting individualtransaction limits and the like, some embodiments allow for a roundingsweep. The rounding sweep allows the user to round the transaction up toa nearest amount (e.g., nearest fifty cents, whole dollar, five dollar,etc.) and have the difference between the transaction amount and therounded amount applied to another function (e.g., accumulated value,savings account, credit account etc.). In accordance with variousembodiments, the user can select the nearest amount and the destinationaccount where the difference should be placed.

In some embodiments of the present invention, the account activationprocess occurs through one or more user interface screens displayedthrough activation portal 110. For example, a first user interfacescreen can be displayed on a terminal in response to a request toactivate a user operation vehicle received through the activation portal110. The first user interface screen is generally capable of receivingone or more accounts to be associated and/or linked to a user operationvehicle and is operable to send a linking request to a user operationvehicle activation system 120.

In response to the linking request, a second user interface screen canbe displayed on the terminal in accordance with various embodiments ofthe present invention. In these embodiments, the second user interfacescreen is able to display the linking and/or activation status for eachof the one or more accounts received on the first user interface screen.For example, in some embodiments, a label, symbol, phrase, or otherindicator can be presented to the user conveying that an account iscurrently not linked to the user operation vehicle, linked to the useroperation vehicle, or a linking request is being processed.

A request for the user to enter a base UIS to be associated with theuser operation vehicle can be made through a third user interface screendisplayed on the terminal. The third user interface screen can, forexample, transmit the base UIS entered by the user to the UIS generationsystem 240 to generate the second UIS for each successfully linkedaccount. In response to a communication from the user operation vehicleactivation system 120, a fourth user interface screen can be presentedwhich displays the second UIS for each of the one or more accountssuccessfully linked.

FIGS. 3A-3C illustrate examples of screenshots for the accountactivation process that can occur through one or more user interfacescreens displayed through activation portal 110 that may be used inaccordance with some embodiments of the present invention. FIG. 3A showsan example of an account user interface screen 300 that can be used insome embodiments. Account user interface screen 300 as illustrated inFIG. 3A can be used for collecting account information about accounts tobe potentially linked to a user operation vehicle, for verifying a userand user operation vehicle for activation purposes, and/or for creatinga new UIS.

In accordance with some embodiments of the present invention, any numberof different types of information can be requested from the user usingaccount user interface screen 300. Account user interface screen 300, asillustrated, requests a user input a user operation vehicleidentification number in entry box 305, loyalty number on the useroperation vehicle in entry box 310, the user's first and last names inentry boxes 315 and 320, respectively, user's data of birth in entry box325, and a current e-mail address in entry box 330. In some embodiments,the type of information requested on account user interface screen 300may depend on the current function of the interface screen (e.g.,account activation vs. account maintenance). Examples of other types ofinformation that can be requested, include, but are not limited to,current user billing address, bank information (e.g., addresses,telephone numbers, routing numbers, etc.) for the account desired to belinked, personal identification numbers for the account desired to belinked, account numbers for the account desired to be linked, mother'smaiden name, answers to security questions, user ID's, passwords, and/orthe like.

FIG. 3B shows an example of a create UIS screen 340 that may be usedwith a user operation vehicle activation interface in accordance withsome embodiments of the present invention. According to someembodiments, create UIS screen 340 can be displayed after the accountverification process is completed and a determination was successfullymade that the user is authorized to activate the account. In theembodiments shown in FIG. 3B, the user is required to enter a four digitnumerical number without spaces or special characters in entry box 345and entry box 350. However, in other embodiments the code can be of anyspecified length and/or include special characters, letters, and/orspaces, or be system generated based on the user information provided.

FIG. 3C shows an example of a change UIS screen 360 that may be usedwith a user operation vehicle activation interface in accordance withsome embodiments of the present invention. According to someembodiments, change UIS screen 360 can be displayed after a usersuccessfully logs into the user's account. In the embodiments shown inFIG. 3C, the user is required to enter a four digit numerical numberwithout spaces or special characters in entry box 365 and entry box 370.However, in other embodiments the code can be of any specified lengthand/or include special characters, letters, and/or spaces.

According to some embodiments of the present invention, once the userhits the submit button (355 or 375) in either create UIS screen 340 orchange UIS screen 360, the new base UIS can be transmitted to the UISgeneration system 240 where an account-specific UIS is created for eachaccount linked to the user operation vehicle.

As previously described, some embodiments of the present invention usean activation portal to activate a user operation vehicle that can beassociated with one or more functions (e.g., credit function, debitfunction, accumulated value function, consumer to consumer function,reward function, store value function, and others). In particular, someembodiments of the present invention use a Java™ applet for useroperation vehicle activation. UIS creation is an example of one taskthat can be provided during user operation vehicle activation. In someembodiments, Java™ applets are used to provide maximum security andencryption to the customer's base UIS that was entered through theactivation portal. For example, in some embodiments, the applets usedfor account-specific UIS creation ensure that the customer's base UIS isnot in clear text anywhere in the system including SSL communicationsbetween web servers and application servers.

While Java™ applets address many of the security concerns associatedwith activating a user operation vehicle and with generating multipleaccount-specific UIS's, some embodiments can use alternative systems andmethods for securely activating the user operation vehicle. Someembodiments of the present invention take advantage of the RSAencryption algorithm for customer UIS encryption before transmitting thebase UIS to a UIS generation system. In particular, the RSA algorithmused in some embodiments may be part of Java™ 5 and the applet classesmay be complied with Java™ 5. However, if the customer's browser has anyversion of Java™ lower than version 5, the UIS creation page may not bedisplayed as desired. Hence, the customer may seek an alternativesolution to the Java™ applet or download a higher version of Java™

In addition, Java™ applets are not compatible with all browsers (e.g.,MAC or Safari). Moreover, in some embodiments, the applets are clientside applications that are downloaded to a client browser. In somecases, the applet may be prevented from loading in the customer'sbrowser. For example, if the applet is trying to run in a client networkthat restricts any outgoing connections for applets or if the securityis set to a maximum level in the client browser. For these situationsand others, some embodiments of the present invention provide systemsand methods for automatically generating multiple account-specific UIS'sin the event of an activation applet failure.

When a customer is activating a user operation vehicle in someembodiments of the present invention, the activation process can directthe customer to a UIS creation applet (e.g., FIG. 3A). In some cases,the user activating the user operation vehicle may desire andalternative to using the applet (e.g., if the user has an incompatiblebrowser). Some embodiments of the present invention provide a hyperlinkthat the user can select if the user desires an alternate solution tousing the Java™ applet. For example, the hyperlink in some embodimentsmight say, “Having issues seeing the applet? Click here to receive asystem generated UIS.”

FIG. 4 illustrates an example of a webpage 400 that might include aJava™ applet 410 for collecting a base UIS from a user along with ahyperlink 420 in accordance with some embodiments of the presentinvention. According to some embodiments, link 420 can point to anotherweb page that can display a message asking the user to confirm theautomatic generation of the multiple account-specific UIS's using asystem selected base UIS. In some embodiments, additional or differenttext can be provided through webpage 400. For example, some embodimentsmight include the following text on webpage 400:

-   -   Enter Your Information    -   Please enter a four-digit user identification string (UIS) in        the required fields below. Your UIS can be used in lieu of a        signature to authorize purchases made with your user operation        vehicle and should only be known by you. Please create a UIS        that is not easy for anyone else to guess and do not write or        share your selected UIS with anyone. We will never ask for your        UIS for any reason.    -   If you are not able to create and verify your new UIS below,        please review the Java™ requirements information at the bottom        of this page. If you are still unable to create your UIS, or if        you would like us to generate a UIS for you please click here to        have our system assign your UIS.

In some embodiments, the system selected base UIS may be the last fourdigits of a number associated with the user (e.g., the user's socialsecurity number). The web page can have a statement indicating theselection of the base UIS (e.g., ‘Last 4 digits of your SSN have beenselected as your initial, or base, UIS for the user operation vehicle.Please click confirm to continue.’). One advantage of automaticallyselecting the base UIS from a number associated with the user is thatthe UIS can be conveyed to the user without actually displaying the UISon a webpage or other mechanism as illustrated in FIG. 5A-5C. Someembodiments provide for a confirmation button to be provided on thispage for the user to confirm that they have noted the base UIS number.

According to some embodiments, the system selected base UIS selectioncan be randomly chosen from one or more pieces of information providedby the user. In some embodiments, a UIS single sign on (SSO) messagepassed from activation portal to UIS generation system contains a numberof numeric fields (e.g., birthday field 325 in FIG. 3A). In accordancewith various embodiments, some fields may be mandatory while otherfields may be optional. In accordance with some embodiments, a baseselection module could be used to select the four digits (e.g., lastfour digits, first four digits, etc.) from one of those fields (with thefield being randomly selected from the available fields) and then usethat as the base UIS. In other embodiments, a set of letters, numbers,special characters, and/or a combination thereof may be selected fromwithin the fields.

For example, in some embodiments, the UIS SSO message may contain one ormore of the following: social security number (SSN), main zip code, homephone number, mobile phone number, work phone number, ABA number, demanddeposit account (DDA) number, birth date, street address, user name,etc. Some embodiments of the present invention may have some, all, ornone of these fields along with other possible fields. Some fields maybe conditional based on inputs from the user, previously enteredinformation, attempts to link new accounts, etc.

Examples of mandatory fields in some embodiments include, but are notlimited to, one or more of the following: main ZIP and home phone (M).Examples of optional fields in some embodiments include, but are notlimited to, the following: work phone and mobile phone. Examples ofconditional fields in some embodiments include, but are not limited to,one or more of the following: SSN, ABA, DDA, and birth date. In someembodiments, all of the fields listed above may be mandatory oroptional. Still yet in some embodiments, some of the examples in onetype of field may be in another field type (e.g., main ZIP may beoptional, conditional, or mandatory in some embodiments).

To produce an account-specific UIS from a four digit base UIS inaccordance with some embodiments of the present invention, one or morenumbers, letters, and/or special characters may be appended to the baseUIS. For example, the number one may be appended to the beginning of thebase UIS and associated with a debit function, the number two may beappended to the beginning of the base UIS and associated with a creditfunction, the number three may be appended to the beginning of the baseUIS and associated with an accumulated value function, the number fourmay be appended to the beginning of the base UIS and associated with aprepaid function, etc.

As an example, suppose the user confirmed the automatic selection of abase UIS by the UIS generation system and the base selection moduleselected the last four digits of the user SSN that was 123456789. Assuch, the system selected base UIS would be 6789. In addition, suppose acredit account, a debit account, an accumulated value account, a prepaidaccount, and a rewards account are linked to the user operation vehicle.Then, the following table illustrates the account-specific UIS's thatwould be generated:

Function Types Linked to the Account- User Operation Vehicle Base UISSpecific UIS Debit 6789 16789 Credit 6789 26789 Accumulated Value 678936789 Prepaid 6789 46789 Rewards 6789 56789

From the four digit UIS that was selected by the base selection module,five new five digit UIS's were created. This is only one example of howsome embodiments of the present invention may create account-specificUIS's in different manners. As discussed in more detail below, someembodiments may use different account-specific generation logic for thegeneration of account-specific UIS's.

According to some embodiments, a response can be sent back from the UISgeneration system 240 to activation portal 110. The response can includea confirmation page or cause a confirmation page to be displayed throughthe activation portal that the UIS generation and/or card activationwere successful.

Some embodiments of the present invention provide for additionalapproaches to solving and/or improving the problems and disadvantagesassociated with using a Java™ applet. In some embodiments, the randomselection of the system selected base UIS can be done on demand orthrough a batch-processing mode. In addition, some embodiments allow fora random base UIS generation option that can be selected by the usereven when no problems with the activation portal exist.

Some embodiments of the present invention use a random field selectorprogram to generate a four digit base UIS. In other embodiments, thebase UIS may be longer or shorter than four digits and may includeletters and/or special characters. There are a variety of differentaccount-specific UIS generation logic sets that can be used to generatethe account-specific UIS (e.g., a 5 digit UIS) that can be used inaccordance with embodiments of the present invention only one of whichwas discussed above.

In some embodiments, the activation portal SSO response can be generatedwith two extra data fields. For example, a field selection data field(e.g. RandomFieldSelected) and a selected digit data field (e.g.,SelectedDigits) could be added in some embodiments. TheRandomFieldSelected=1 could be used to indicate the SSN number, 2 forthe main zip code, 3 for ABA, 4 for DDA, etc. Similarly, theSelectedDigits=1 can be used to indicate the selection of the first fourdigits of the selected field and 2 for the last four digits of theselected field. The values for these data fields indicate the requesteddata field that was selected and which part of the data field was usedto generate the system generated base UIS. In accordance with someembodiments, the UIS generation system 240 can send a mapping list tothe activation portal before using this feature. In other embodiments,the mapping can be sent with the response.

In some embodiments, activation portal 110 can send a confirmation emailto the user that the card is activated, the base UIS used (whetherentered by the user or system selected), a clue for the user to knowwhich base UIS was used (e.g., the first four digits of your checkingaccount number), and/or the account-specific UIS's that were generatedfor each account. In some embodiments, the activation portal may onlydisplay the confirmation page in the customer browser. One example of amessage that can be used in accordance with embodiments of the presentinvention is “The card has been activated successfully and last fourdigits of your SSN were used for the user operation vehicle UIS.” Inother embodiments, a confirmation screen may display only a customercare number and instruct the user to call the number (e.g., immediately,after twenty four hours, or some other time period) to receive thegenerated account-specific UIS.

According to some embodiments, an account boarding batch file can besent from the multi-function user operation vehicle core platform to theUIS generation system every night (or other specified time period suchas every hour, every two hours, etc.). In some embodiments, the accountboarding batch file can contain any new accounts/user operation vehiclesboarded in the system. This batch file can be used as a trigger togenerate base UIS requests for newly boarded customers. In accordancewith some embodiments, the boarding file format can include extra fieldsthat are present in the activation portal SSO request but are notpresent in existing account boarding files. One example of an extrafield is the ABA Number. Additional error codes can also be sent fromthe UIS generation system 240 to the user operation vehicle coreplatform for new fields. In some embodiments, the user operation vehiclecore platform may contain the processing logic for these error codes.

Some embodiments include batch processing logic for UIS reject records.The UIS generation system can include a processing module to process theaccount boarding file (and data fields). In addition, some embodimentsof the UIS generation system can include an error module to detecterrors and inform the user operation vehicle core platform of all newerror codes for all the new data fields. Some embodiments of the UISgeneration system can select newly boarded customers from the accountboarding file and generate customer base UIS's using customer data andcan send these to a verification system for recordation. Any rejectresponse from the verification system can be recorded and can be sent tothe user operation vehicle core platform in a reject batch file.

FIG. 6 is a block diagram 600 illustrating components of an activationportal 110 that may be used in accordance with some embodiments of thepresent invention. According to the embodiments shown in FIG. 6,activation portal 110 can include memory 610, processor 620, activationinterface module 630, account entry and verification module 640,encryption/decryption module 650 (sometimes called an encryptor ordecryptor), and communications module 660. Other embodiments of thepresent invention may include some, all, or none of these modules andcomponents along with other modules or application components. Stillyet, some embodiments may incorporate two or more of these modules intoa single module and/or associate a portion of the functionality of oneor more of these modules with a different module. For example, in someembodiments, the account entry and verification module 640 can beseparated into two or more modules. According to some embodiments,activation portal 110 is a component that includes hardware such asmemory 610 and processor 620. However, in other embodiments, activationportal 110 refers to a software application that can be run on hardwaresuch as a personal computer.

Memory 610 can be any device or mechanism used for storing information.In accordance with some embodiments of the present invention, memory 610is intended to encompass any type of, but is not limited to, volatilememory, nonvolatile memory and dynamic memory. For example, memory 610can be random access memory, memory storage devices, optical memorydevices, magnetic media, floppy disks, magnetic tapes, hard drives,SIMMs, SDRAM, DIMMs, RDRAM, DDR RAM, SODIMMS, erasable programmableread-only memories (EPROMs), electrically erasable programmableread-only memories (EEPROMs), compact disks, DVDs, and/or the like. Inaccordance with some embodiments, memory 610 may include one or moredisk drives, flash drives, databases, local cache memories, processorcache memories, relational databases, flat databases, and/or the like.In addition, those of ordinary skill in the art will appreciate manyadditional devices and techniques for storing information can be used asmemory 610.

Memory 610 may be used to store instructions for running one or moreapplications or modules on processor 620. For example, memory 610 couldbe used in some embodiments to house all or some of the instructionsneeded to execute the functionality of activation interface module 630,account entry and verification module 640, encryption/decryption module650, and/or communications module 660.

Activation interface module 630, according to some embodiments of thepresent invention, provides an interface for user 105 to accessactivation portal 110 and communicate with activation system 120,verification system 220, UIS generation system 240, and/or othercomponents or systems. In some embodiments, activation interface module630 provides one or more graphical user interfaces that can be displayedon a terminal and allow for interaction from user 105. For example,activation interface module 630 may display account user interfacescreen 300 as illustrated in FIG. 3A, create UIS screen 340, change UISscreen 360, or others.

In accordance with some embodiments of the present invention, accountentry and verification module 640 is operable to receive accountinformation from the user through activation interface module 630. Thiscan be done, for example, through one or more graphical user interfaces(e.g., account user interface screen 300), numerical pad on the phone,or the like. The account information can be the user operation vehicleaccount information in some embodiments. Accordingly, account entry andverification module 640 takes the received user operation vehicleaccount information and any additional verification information (e.g.,user's birthday, answers to security questions, telephone numbers,and/or the like) and performs a verification check that the user isauthorized to access the account.

Once the user operation vehicle account information is verified and theuser is granted access to the account, some embodiments allow the userto submit account information about one or more payment functions thatthe user desires to link to the user operation vehicle. For example, theuser could enter account information for one or more credit functions,reward functions, debit functions, prepaid functions, and/or the like.Then account entry and verification module 640 could process the requestto verify the authenticity of each account and then link the desiredaccounts. In accordance with some embodiments, account entry andverification module 640 could use rules set up by system administratorsto process the request to verify the accounts can be linked to the useroperation vehicle. Examples of the types of rules that may be usedinclude, but are not limited to, correct routing numbers, correctaccount numbers, only participating institutional accounts can belinked, only accounts from a single user, and/or the like.

In some embodiments, activation interface module 630 is operable toreceive a base user identification string from user 105. As described inmore detail below, the UIS generation module 250 can use UIS generationlogic and the base UIS to generate a unique account-specific UIS foreach function linked (or a subset of the functions linked) to the useroperation vehicle.

The account information received through account entry and verificationmodule 640 is usually encrypted before it is transferred over network115 to activation system 120, verification system 220, or UIS generationsystem 240. This encryption can be done using encryption/decryptionmodule 650. In some embodiments, the encryption/decryption may be a softencryption using software. In other embodiments, theencryption/decryption may be done using only hardware components or acombination of hardware and software components. In some embodiments,encryption/decryption module 650 can include one or more nCipher hostsecurity modules (HSM) (e.g., a cluster of nCipher HSMs). Examples ofthe types of encryption schemes that can be used include, but are notlimited to, triple data encryption standard (DES3), advanced encryptionstandard (AED), Hypertext Transfer Protocol over Secure Socket Layer(https), secured socket layer (SSL), transport layer security (TLS),public/private key encryption, and others known to those of ordinaryskill in the art.

Communications module 660 in some embodiments of the present inventionis configured to manage and translate any requests from user 105, from agraphic interface screen, into a format required by the destinationcomponent and/or system. Similarly, communications module 660 may beused to communicate between systems and/or modules that use differentcommunication protocols, data formats, or messaging routines. Accordingto some embodiments, system components can communicate through one ormore of the following messaging methods: ISO 8583 Standard for FinancialTransaction Card Originated Messages, extensible markup language (XML),proprietary message formats, and/or others known to those of ordinaryskill in the art.

FIG. 7 is a block diagram 700 illustrating components of a UISgeneration system (UIS generator) 240 that may be used in accordancewith some embodiments of the present invention. According to theembodiments shown in FIG. 7, UIS generation system 240 can includememory 710, processor 720, UIS generation module 250, base selectionmodule 740, encryption/decryption module 750, communications module 760,random field selection module 770, random field portion generator 780,and random mapping generator 790. Other embodiments of the presentinvention may include some, all, or none of these modules and componentsalong with other modules or application components. Still yet, someembodiments may incorporate two or more of these modules into a singlemodule and/or associate a portion of the functionality of one or more ofthese modules with a different module. For example, in some embodiments,random field selection module 770, random field portion generator 780,and random mapping generator 790 may be combined into a single module.According to some embodiments, UIS generation system 240 is a componentthat includes hardware such as memory 710 and processor 720. However, inother embodiments, UIS generation system 240 refers to a softwareapplication that can be run on hardware such as a personal computer.

Memory 710 can be any device or mechanism used for storing informationas described above with reference to memory 610. Memory 710 may be usedto store instructions for running one or more applications or modules onprocessor 720. For example, memory 710 could be used in some embodimentsto house all or some of the instructions needed to execute thefunctionality of UIS generation module 250, base selection module 740,encryption/decryption module 750, communications module 760, randomfield selection module 770, random field portion generator 780, and/orrandom mapping generator 790.

Base selection module 740, according to some embodiments of the presentinvention, could be used to select a set of digits (e.g., last fourdigits, first four digits, etc.) from one of the fields populated by theuser through activation portal 110. In some embodiments, the field beingrandomly selected from the available fields by random field selectionmodule 770. Once the field is selected, the random field portiongenerator selects which portion of the field will be used as the baseUIS. For example, the last four digits, the first four digits, the thirdthrough sixth digit, etc. In other embodiments, the random field portiongenerator may select a set of letters, numbers, special characters,and/or a combination thereof as the portion to be used as the base UIs.

In some embodiments, encryption/decryption module 750 can encrypt and/ordecrypt any messages sent or received by communication module 760 andbetween individual components of the UIS generation system. In someembodiments, the encryption/decryption may be a soft encryption usingsoftware. In other embodiments, the encryption/decryption may be doneusing only hardware components or a combination of hardware and softwarecomponents. Examples of the types of encryption schemes include, but arenot limited to, those listed for encryption/decryption module 650 inFIG. 6. Similar to communications module 660, communications module 760may be used to communicate between systems and/or modules that usedifferent communication protocols, data formats, or messaging routines.

As previously described, the activation portal SSO response sent fromUIS generation system 240 can be generated with two extra data fields(e.g., RandomFieldSelected and SelectedDigits). In accordance with someembodiments, the mapping between the extra two data fields and thecorresponding fields from which the information is gathered can bechanged periodically to increase security. In some embodiments, randommapping generator 790 determines the mapping scheme currently beingused. For example, the RandomFieldSelected=1 could be initially set toindicate the SSN number, 2 for the main zip code, 3 for ABA, 4 for DDA,etc. A new mapping can be generated by random mapping generator 790 andcommunicated to activation portal 110 using communications module 760.

FIG. 8 is a flowchart illustrating one example of a method 800 foroperation of activation portal 110 in accordance with some embodimentsof the present invention. As indicated previously, activation portal 110facilitates the exchange of information between activation system 120and user 105 for the activation of a user operation vehicle. Referringto FIG. 8 in conjunction with FIG. 1, according to some embodiments ofthe present invention, activation system 120 can receive a set UISrequest or a change UIS request through activation portal 110 duringreceiving operation 810. The request can come from a software programfor changing or setting a UIS, a graphical user interface screen, awebpage, a telephone call with navigation through menus using thenumerical keypad on the phone, a proprietary interface, and/or the like.

Once a request to set a UIS or change a UIS occurs during receivingoperation 810, a response can be generated that is appropriate to thesystem through which the request originated. For example, if the requestoriginated from a web page, a set/change UIS webpage can be generatedand forwarded to the user 105 in forwarding operation 820. In this case,user 105 enters a base UIS on the set/change UIS webpage which is thenencrypted and returned to activation system 120. Activation system 120receives the encrypted UIS at receipt operation 830 and then decryptsthe encrypted UIS during production operation 840. Once the base UIS isdecrypted, some embodiments provide for UIS generation logic to beapplied to the base UIS to generate an account-specific UIS for eachaccount linked to the user operation vehicle. Each account-specific UISis then encrypted and stored.

According to some embodiments that will be discussed below, varioustypes of UIS generation logic can be used to create the account-specificUIS for each account linked to the user operation vehicle. Once anaccount-specific UIS is generated for each function, confirmationoperation 850 can be used to generate a completion screen and/or send aconfirmation e-mail or other type of message (e.g., letter, automatedphone call, etc.).

FIG. 9 is a flowchart illustrating an exemplary set of UIS generationlogic 900 for generating multiple user identification strings inaccordance with some embodiments of the present invention. A base UIS isreceived at receipt operation 910. As previously discussed, the base, ororiginal, UIS can originate from a user activating the user operationvehicle or requesting a UIS change. In the embodiments illustrated inFIG. 9, once the base UIS is received and processed, user determinationoperation 920 determines the authorized payment types (or functions)associated with the user operation vehicle.

For example, in accordance with some embodiments of the presentinvention, a user operation vehicle may be pre-associated with one ormore payment functions before the user operation vehicle is offered to auser. One or more user operation vehicle type codes can be associatedwith the user operation vehicle offered to the user in some embodiments.The one or more type codes indicate pre-associated functions that can belinked to the user operation vehicle. For example, if there was a debitfunction, a credit function, and a prepaid function, there would be atmost seven combinations of functions that are pre-associated and thatcan be linked (i.e., credit function, debit function, prepaid function,credit and debit function, credit and prepaid function, debit andprepaid function, and credit, debit and prepaid function). According tosome embodiments, a type code can be associated with one or more ofthese options allowing a user to quickly link the desired combination ofassociated functions in a quick manner.

During the activation process, the user operation vehicle type code canbe used to access (e.g., from a database) a list of the functions,corresponding to the user operation vehicle type code, that are to belinked to the user operation vehicle. In other embodiments, the useroperation vehicle type codes may be used at a POI to activate a set offunctions (or those functions associated with the code that are not yetactivated). In some embodiments, a user may go to a store that is havinga special promotion involving providing linking a new line of credit (oreven a prepaid card) to the user operation vehicle subject toqualification of the user. The store can provide a promotion code thatthe user submits to associate and/or link the new payment function(e.g., store credit) that may not already be associated and/or linked tothe user operation vehicle. In some embodiments, the promotion code canbe entered during a purchase at the store. If the promotion code isaccepted, the code may be processed immediately or stored for processing(e.g., credit approval, association, linking, etc.) in a batch mode atsome later time or after the occurrence of some triggering event.

In some embodiments, the user is shown different accounts and doesn'tactivate all of them. The user can then be provided activation codeswhich the user can send to activate an account at a later time.According to some embodiments, these activation codes may be processedthrough a variety of systems including, but not limited to, telephonesystems, internet accessed systems, through appending the activationcode to a UIS at a POI device, interactions with a customer servicerepresentative, and others systems, methods, and means.

Using the base UIS and the determined authorized payment types,account-specific UIS generation operation 930 creates a uniqueaccount-specific UIS for each account associated with the user operationvehicle. According to some embodiments, the account-specific UIS can begenerated by appending one more additional numbers, letters, specialcharacters and/or the like to the end of a base UIS entered by the userfor each account linked to the user operation vehicle. For example, toproduce an account-specific UIS in one or more embodiments, the numberone is appended to the end of the base UIS and associated with a debitfunction, the number two is appended to the end of the base UIS andassociated with a credit function, the number three is appended to theend of the base UIS and associated with an accumulated value function,the number four is appended to the end of the base UIS and associatedwith a prepaid function, etc. The following table illustrates this ideawhere the user entered the original UIS once as 2254 and a creditaccount, a debit account, an accumulated value account, a prepaidaccount, and a rewards account are linked to the user operation vehicle:

Function Types Linked to the User Account-Specific Operation VehicleBase UIS UIS Debit 2254 22541 Credit 2254 22542 Accumulated Value 225422543 Prepaid 2254 22544 Rewards 2254 22545

From the four digit UIS that the user entered, five new five digit UIS'swere created. In accordance with some embodiments, any set of differentnumbers (or even letters and/or special characters) may be appended atthe end of the UIS to indicate these functions. For example, the letter“c” could be used for credit, the letter “d” could be used for debit,the letters “av” could be used for accumulated value, the letter “p”could be used for a prepaid function, and the letter “r” could be usedfor a reward function.

If there are more than one function type (e.g., two debit functions) tobe associated with the user operation, one or more additional numberscould be appended after the payment type in some embodiments. Thefollowing table illustrates this idea where the user entered theoriginal UIS once as 2254 and there are three credit functions, twodebit functions, no accumulated value functions, one prepaid function,and one rewards function:

Function Types Linked to the User Account-Specific Operation VehicleBase UIS UIS Debit 1 2254 225411 Debit 2 2254 225412 Credit 1 2254225421 Credit 2 2254 225422 Credit 3 2254 225423 Prepaid 2254 225441Rewards 2254 225451

From the four digit base UIS that the user entered, seven new six digitUIS's were created where the first four numbers are the base UIS, thefifth number corresponds to a payment type and the sixth number refersto the account within that payment type. Of course, any number,character, special character, or string thereof could be used toindicate payment type and account number. In accordance with someembodiments, any set of different numbers (or even letters and/orspecial characters) may be appended at the end of the base UIS toindicate these functions. For example, the characters “c1”, “c2”, and“c3” could be used for a first, second, and third credit, the characters“d1” and “d2” could be used for a first and second debit, the characters“p1” could be used for a first prepaid function, and the characters “r1”could be used for a first reward function.

Another example of the type of UIS generation logic that could beapplied to generate account-specific UIS's for each function is addingor subtracting a value to the base UIS (i.e., incrementing the base UIS)entered by the user. As a simple example, the number one could be addedto the base UIS and the result associated with a debit function, thenumber two could be added to the base UIS and the result associated witha credit function, the number three could be added to the original UISand the result associated with an accumulated value function, etc. Thefollowing chart illustrates this idea:

Function Types Linked to the User Base Account-Specific OperationVehicle UIS Offset UIS Credit 2254 +1 2255 Debit 2254 +2 2256Accumulated Value 2254 +3 2257 Prepaid 2254 +4 2258 Rewards 2254 +5 2259

In other cases, offsets could be used. For example, any set of numberssuch as 100, 200, 300, etc. could be used for credit, debit, accumulatedvalue, etc. Similarly, where the user operation vehicle has more thanone of the same function, additional numbers could be added and/orsubtracted. For example, an additional 10 for each account. Thefollowing table illustrates this idea where the user entered the baseUIS once as 2254 and there are two credit functions, three debitfunctions, no accumulated value functions, one prepaid function, and onerewards function:

Account- Function Types Linked to the Base Function Account SpecificUser Operation Vehicle UIS Offset Number UIS Credit 1 2254 100 1 2355Credit 2 2254 100 2 2356 Debit 1 2254 200 1 2455 Debit 2 2254 200 2 2456Debit 3 2254 200 3 2457 Prepaid 2254 400 1 2655 Rewards 2254 500 1 2755

From the four digit base UIS that the user entered, seven new four digitUIS's were created from the one base UIS. Again, these examples aremeant to be exemplary of the types of UIS generation logic that might beapplied and are not meant to be limiting in any way. In fact, anyoperation (e.g., add, subtract, multiply, divide, etc.) or combinationof operations that result in a unique account-specific UIS for eachaccount associated with the user operation vehicle would work. Inaddition, the illustrations shown show a four digit numerical UIS beingentered by the user and numerical account-specific UIS's. This is notthe case in every embodiment and is only meant to illustrate variousideas and, in some embodiments, letters, numbers, special characters,and the like may be used for the base UIS and/or the additionalcharacters used to generate the account-specific UIS.

In accordance with some embodiments, the user is able to select from aset of UIS generation logic options for the creation of the multipleaccount-specific UIS's that will be associated with the user's useroperation vehicle. In addition, the users of some embodiments of thepresent invention are provided with an option to decide how the accountsof a similar type are ordered, how the function types are ordered, theoffset associated with each function type, and/or other parameters inthe creation of the multiple account-specific UIS.

In addition to credit, debit, prepaid, rewards, accumulated value andother payment functions with immediate processing, other differentpayment processing options can be linked to or used with the useroperation vehicle in accordance with some embodiments of the presentinvention. For example, payment options or arrangements such as sixtydays same as cash, ninety days same as cash, one-hundred eight days sameas cash and the like may be available to be linked and/or used.Similarly, for debit functions, prepaid functions, reward functions, andother functions, the user payment options may include a delayeddeduction meaning the payment will not be processed for a specifiedperiod of time (e.g., three days, seven days, thirty days, and thelike). A determination can be made that the user is credit worthy forthese options, but the options are not activated until a code is enteredby the user at a POI. Some options may have expiration dates whileothers may not.

For example, suppose a user has been granted a sixty days same as cashoffer and the user has the following UIS strings associated with theuser operation vehicle:

Function Types Linked to the Account- User Operation Vehicle Base UISSpecific UIS Debit 2254 22541 Credit 2254 22542 Prepaid 2254 22543Rewards 2254 22544

When a user goes to a store to purchase merchandise and wants to payusing the sixty days same as cash offer, the user can enter theaccount-specific UIS choosing the payment function followed by a paymentoption code (e.g., “60” to indicate sixty days same as cash) which hasbeen communicated to the user. To activate this payment option the userwould enter the modified UIS as 2254260 to pay with credit using thesixty days same as cash option. These payment codes can be anything thatindicates payment options. Some examples of payment option codesinclude, but are not limited to, “90” to indicate ninety days, “180” toindicate one-hundred eighty days, “s” to indicate sixty days, “n” toindicate ninety days, “o” to indicate one-hundred eighty days.

In some embodiments, the account-specific UIS's are stored in anencrypted system possibly managed by a third party. As a result, in someembodiments, there might not be a way of determining the base UIS afterthe card activation or change UIS events have occurred. In order tooffer special promotions via UIS some embodiments set up additionalUIS's when the customer selects their base UIS. In some cases, thenumber of additional UIS's set up are based on a set of promotionsplanned in advance. In some embodiments, as additional new promotionsare planned beyond the scope of the original set of planned promotions,the user can be requested to change the UIS's associated with the useroperation vehicle. One advantage of this approach is the enhancedsecurity that is created by the user being encouraged to change theirUIS's regularly in order to be able to take advantage of new promotions.In some embodiments, the system allows the customer to select their ownUIS during card activation that can then be used for special offers,transactions, etc.

In some embodiments, the base UIS can be determined by decrypting anencrypted base UIS, if stored, or one or more of the account-specificUIS's. Then, promotion-specific UIS's can be created that are associatedwith one or more promotions. In some embodiments, the promotion-specificUIS's can be generated based on the automatic UIS generation systemdescribed above. For example, using the automatic UIS generation, a onetime UIS can be created from the customer's data. Suppose a promotion togive a customer a percentage point bonus (e.g., ten percent), percentagediscount, etc after a number (e.g., 10) of successfully processedtransactions. A promotion-specific UIS could be generated from thecustomer's data (e.g., last four-digits of a phone) followed by thenumber 10. An email, SMS, outbound voice message from a voice responseunit, letter, fact, etc could be sent to the customer to advise themthat if they enter that promotion-specific UIS on a transaction of theirchoice, they'll get the bonus. In addition, the term account-specificUIS's can include promotion-specific UIS's in some embodiments of thepresent invention since the reward or reward actions can be viewed asthe account balance.

FIG. 10 illustrates an example of online transaction processing (onlineauthorization request processing) which may be used in some embodimentsof the present invention. When a user makes a purchase through an onlineretailer or merchant 1010 a single sign on (SSO) message can begenerated. In some embodiments, the SSO message can include varioustypes of information about the transaction or purchase including, forexample, purchase amounts. Once generated, the SSO message can be passedto UIS purchase page module 1015. Module 1015 generates a UIS purchasepage that can be displayed through a webpage to the customer making apurchase from online retailer 1010. The UIS purchase page in someembodiments of the present invention can include a section for thecustomer to enter user operation vehicle identification informationalong with a UIS. The customer can then enter the UIS corresponding tothe payment function the customer desires to use to complete thepurchase.

The purchase details (e.g., purchase amount, user operation vehicleidentification information, etc.) and the UIS entered by the customercan then be sent to the user operation vehicle platform 1020. Inaccordance with some embodiments, user operation vehicle platform 1020validates the purchase details and the user operation vehicleinformation. If the details and information are not corrupted, a useroperation vehicle purchase transaction request can be generated by useroperation vehicle platform 1020. In some embodiments, the user operationvehicle transaction request is transferred to bank network switch 1025over a communications network, leased line, dedicated communicationschannel, or the like.

Once the user operation vehicle transaction request is received, banknetwork switch 1025 routes the transaction to verification system 1030over a communications network, leased line, dedicated communicationschannel, or the like. Verification system 1030 can then validate the UISentered by the customer, determine the function associated with the UIS(e.g., debit, credit, accumulated value, etc.), and generate a functionpayment authorization request. Once generated, the function paymentauthorization request can be transferred to bank network switch 1025.

In accordance with various embodiments, bank network switch 1025 candetermine which function is authorized to be charged. In someembodiments, the determination is made based on the message formatand/or message content. Once a determination is made, the functionpayment authorization request can be routed to the corresponding useroperation vehicle function system 1035 that can include one or morefunction processing systems (e.g., credit processing system, debitprocessing system, etc.). The selected function processing systemprocesses the request and returns an authorization response back to banknetwork switch 1025.

In some embodiments, the authorization response can be routed from banknetwork switch 1025 to verification 1030, where the response isprocessed and then returned to bank network switch 1025. From the banknetwork switch, the authorization response is routed to user operationvehicle platform 1020 which generates and returns an approval or denialmessage back to online retailer 1010.

According to some embodiments, a daily settlement process 1050 occursbetween online retailer 1010, user operation vehicle function systems1035 (e.g., accumulated value processing system, debit processingsystem, credit processing system, etc.), and verification system 1030.In some embodiments, daily settlement files are generated based on thepayments processed. Some embodiments use bank settlement control module1040, verification settlement control module 1045, and retailersettlement control module 1055 to generate daily settlement files whichare processed through daily settlement process 1050 between the onlineretailer and function account holders. While not illustrated in FIG. 10,in some embodiments, daily settlement process 1050 is routed to theretailer settlement control module 1055 through bank switch 1025.

FIG. 11 illustrates an example of an operating environment 1100 in whichsome embodiments of the present invention may be utilized. In theembodiments illustrated in FIG. 11, a user can make a purchase at POIdevice 1105 after activating the user operation vehicle. According tosome embodiments, using one of the generated account-specific UIS's, theuser can select which payment function will be used to process thetransaction. In addition, some embodiments of the present inventionprovide for the addition of functionality (e.g., rewards, roundingsweep, etc.) to the UIS for use at a POI device 1105.

FIG. 11 includes various components including a POI device 1105, POIapplication 1110, network 1115, UIS and reward verification system 220,UIS database 230, rewards database 1120, network 1125, credit processingsystem 1130, debit processing system 1135, rewards processing system1140, and other processing systems represented by 1145. Examples ofother processing systems include, but are not limited to, store valueprocessing systems, gift card processing systems, consumer to consumerpayment systems, proprietary payment systems, as well as others.

According to some embodiments, a user can append additional charactersto the end of the UIS at POI device 1105. In some embodiments, POIdevice 1105 can be a point of sale device, or comprised of componentsand/or software, purchased from Advanced Retail Management Systems,Microsoft dynamics RMS, Retail Pro, CounterPoint or other vendors.

By appending additional characters to the end of the UIS, the usercreates a modified UIS (MUIS). However, according to some embodiments ofthe present invention, POI device 1105 treats a MUIS and a UIS in thesame manner. POI device 705 processes all of the information received(e.g., the user operation vehicle account number, modified UIS,transaction information, merchant information, and possibly otherinformation) and generates a total string of characters. The totalstring of characters can include various pieces of information such as,but not limited to, a primary account string, a user identificationstring (UIS), a function selector, a reward code, a modified UIS,merchant code, and/or the like.

The string of characters is typically partially encrypted by anencryption/decryption module associated with the POI, although in someembodiments it may be entirely encrypted or not encrypted at all. Forexample, in some embodiments, the UIS (or MUIS) would be encrypted, theaccount number would not be encrypted, and other pieces may or may notbe encrypted depending on the technology, administrator preferences,and/or protocols set in place. The string of characters is thentransmitted across network 1115 to verification system 220 in accordancewith various embodiments of the present invention. Then, the string ofcharacters can be parsed into the various tokens (e.g., the primaryaccount string, the UIS, the function selector, and/or the reward code)using parsing logic.

In some embodiments of the present invention, the user and/or rewardcode can be validated using one or more of the various tokens. Forexample, the validation can occur by comparing a user operation vehicleUIS stored in UIS database 230 that is associated with the primaryaccount number with the UIS received in the string of characters.Similarly, a determination of a reward action associated with the rewardcode can be made. The determination of the reward action can occur in anumber of different ways according to various embodiments of the presentinvention. For example, in some embodiments, the reward determinationcan be performed by looking up the reward code in reward code database1120. As another example, the reward determination can be performed bydeciphering the reward code into various tokens that correspond tovarious reward elements.

Once the reward code is determined and applied, a payment request canthen be sent for processing. In some embodiments, the payment processingoccurs through a function indicated by a function selector. For example,the function selector can indicate that payment processing occur througha credit processing system 1130, a debit processing system 1135, arewards processing system 1140, other processing systems 1145 (e.g.,store value, gift card, consumer to consumer, prepaid, etc.), and/or thelike.

In some embodiments, the user can select a rounding sweep option thatwill result in a set of UIS's being generated that will result in arounding sweep for a particular account. In some embodiments, however,no additional UIS's are generated, but a user code is supplied to theuser allowing the user to create a MUIS at the merchant that will resultin the rounding sweep. In accordance with some embodiments, the amountsset for the rounding sweep can be one dollar, five dollars, and tendollars. In some embodiments, the corresponding user code can be thenumbers one, five, and ten. However, in other embodiments, differentuser codes and amounts may be used, and more or less rounding optionsmay be available. In accordance with some embodiments, the accountspecified by the user for the rounding sweep deposit could be a savingsaccount, or any other account, from any bank, merchant, etc. As a resultof the rounding sweep in some embodiments a decoupled savings orindependent savings is created.

As such, the user can select, at a POI, an account-specific UIS fordebit (e.g., 3345) would result in an ACH debit of that amount. Forexample, when the user makes a $33.37 purchase through a POI and usesthe account-specific UIS for debit, a corresponding $33.37 ACH debitwould be generated. In some embodiments, an MUIS corresponding to theaccount-specific UIS for debit followed by the number one (e.g., 33451)would result in a round up to the nearest dollar and the differencebetween the transaction amount at the merchant and the rounded amountbeing deposited in a specified account. So, for example, a $33.37purchase through a POI using the MUIS of account-specific UIS for debitfollowed by the number one (e.g., 33451) would result in a $34.00 ACHDebit and $0.63 would be deposited into the accumulated value account, asavings account, etc. that was specified by the user.

In some embodiments, an MUIS corresponding to the account-specific UISfor debit followed by the number five (e.g., 33455) would result in around up to the nearest five dollars. So, a $33.37 purchase using theMUIS of account-specific UIS for debit followed by the number five(e.g., 33455) would result in a $35.00 ACH Debit and $1.63 would beplaced in an accumulated value account, a savings account, etc. that wasspecified by the user. In some embodiments, an MUIS corresponding to theaccount-specific UIS for debit followed by the number ten for debitfollowed by the number five (e.g., 334510) would result in a round up tothe nearest ten dollars. So, a $33.37 purchase using the MUIS ofaccount-specific UIS followed by the number five (e.g., 334510) wouldresult in a $40.00 ACH debit and $6.63 would be placed in an accumulatedvalue account, a savings account, or other account that was specified bythe user.

In some embodiments, part of the MUIS contains an identifier identifyingthe system for processing and possibly a delayed payment option. Forexample, a user may enter a MUIS as “987613.” In some embodiments, thefirst four characters are the user identification string, the fifthcharacter is the processing identifier, and the sixth character as thepayment option. In this example, the system will recognize that “9876”is the user identification string. The system will also identify “1” asan identifier identifying, e.g., the debit processing system. In someembodiments, the payment option “3” means that the funds will beprocessed three days later. If the customer is not eligible for thedelayed payment option, or if the token is not valid or unrecognized,the system can ignore the token and continue to process the transactionor, in some embodiments, decline the transaction. The delayed paymentoption can be set up to be anything. For example, the delayed paymentoption token can correspond to equal monthly installment payments (e.g.,“5” means five equal monthly installments), delayed payments (e.g., “4”means a four day delay before processing), as well as others. Accordingto some embodiments, the delayed payments may be processed in a batchprocessing mode discussed in more detail below with regard to FIG. 15.

In the embodiments illustrated in FIG. 11, the processing systems1130-1145 are different entities and may be located at differentphysical locations or use unique routing information. In someembodiments, however, the processing systems are part of a centralizedsystem which includes one or more payment processing subsystems forprocessing credit, debit, rewards, prepaid, consumer to consumerpayments, and the like. As such, when the payment is received at thecentralized system, a determination is made as to how the payment shouldbe processed.

In some embodiments, the processing systems 1130-1145 are incommunication with one another (e.g., through network 1125, through adedicated communications channel, etc.). Accordingly, this allows theprocessing systems to interact in the application of rewards, infacilitating the splitting of payment across one or more paymentfunctions, and/or the like.

FIG. 12 is a block diagram illustrating components of a POI device 1205that may be used in accordance with some embodiments of the presentinvention. POI device 1205 can be a standard POI device currently in usetoday, or a new device with increased functionality. According to theembodiments shown in FIG. 12, POI device 1105 includes memory 1210,processor 1220, power supply 1230, POI application 1110, user interfacemodule 1240, encryption/decryption module 1250, and communicationsmodule 1260. Other embodiments of the present invention may includesome, all, or none of these modules and components along with othermodules and/or application components. Still yet, some embodiments mayincorporate two or more of these modules into a single module and/orassociate a portion of the functionality of one or more of these moduleswith a different module. For example, in some embodiments, userinterface module 1240 can be combined with POI application 1110.

Memory 1210 can be any device or mechanism used for storing information.In accordance with some embodiments of the present invention, memory1210 is intended to encompass any type of, but is not limited to,volatile memory, nonvolatile memory and dynamic memory. For example,memory 1210 can be random access memory, memory storage devices, opticalmemory devices, magnetic media, floppy disks, magnetic tapes, harddrives, SIMMs, SDRAM, DIMMs, RDRAM, DDR RAM, SODIMMS, erasableprogrammable read-only memories (EPROMs), electrically erasableprogrammable read-only memories (EEPROMs), compact disks, DVDs, and/orthe like. In accordance with some embodiments, memory 1210 may includeone or more disk drives, flash drives, databases, local cache memories,processor cache memories, relational databases, flat databases, and/orthe like. In addition, those of ordinary skill in the art willappreciate many additional devices and techniques for storinginformation can be used as memory 1210.

In some embodiments, memory 1210 can be used to store instructions forrunning one or more applications or modules on processor 1220. Forexample, memory 1210 could be used to house all or some of theinstructions needed to execute the functionality of POI application1110, user interface module 1240, and/or communications module 1260.

Some embodiments of POI device 1105 include power supply 1230 which canbe any type of device that supplies the necessary power required by POIdevice 1105. For example, power supply 1230 may be an independentrechargeable battery, multiple batteries, and/or other external powersupplies. The power supply may be internal or external to POI device1105. For example, external power may be supplied by accessing a powergenerator, solar grid, power line, and/or the like.

POI application 1110 can, in accordance with some embodiments, offeradditional intelligence to POI device 1105. For example, POI application1110 can include intelligence systems such as real-time inventoryinformation. In some embodiments, part of the reward verification systemin verification system 220 may be accessed through POI application 1110.For example, each store could create a reward system through whichadditional strings of numbers appended to the beginning, end, or withinthe UIS could be validated and applied to the transaction.

User interface module 1240 includes any hardware and software componentsfor interaction with a user. For example, in some embodiments, userinterface module 1240 is a numerical keypad with software running onprocessor 1220 which monitors for entry of UIS. Decryption/encryptionmodule 1250 is used to encrypt any information that has to betransferred across network 1115 and decrypt any incoming messages thatare encrypted. Communications module 1260 in some embodiments of thepresent invention is configured to translate any messages from POIdevice 1105 into a format required by the destination component and/orsystem. For example, communication protocols for peripheral devicesand/or computers include, but are not limited to, ADM 787/788, AEDEX, CD5220, DSP-800, EPSON Esc/POS, UPOS, industry standard PoS protocols,proprietary protocols and the like. Similarly, communications module1260 can route encrypted messages to decryption module 1250 and canrequest encryption module 1250 encrypt outgoing messages.

FIG. 13 is a block diagram illustrating components of a verificationsystem 1300 that may be used in accordance with some embodiments of thepresent invention. According to the embodiments shown in FIG. 13,verification system 220 can include communications module 1310,encryption/decryption module 1320, parsing module 1330, UIS verificationmodule 1340, function determination module 1350, function routing module(switch) 1360, and reward verification module 1370. Other embodiments ofthe present invention may include some, all, or none of these modulesalong with other modules and/or application components. Still yet, someembodiments may incorporate two or more of these modules into a singlemodule and/or associate a portion of the functionality of one or more ofthese modules with a different module.

According to some embodiments of the present invention, an authorizationrequest (or a transaction request) is received at verification system220 from a POI device. All requests may be received throughcommunications module 1310 which is able to receive all incomingrequests and/or messages, and direct the requests and/or messages to thecorrect module for processing.

In some embodiments, an incoming authorization request may be encrypted.When such a request is received at communications module 1310, therequest is routed to encryption/decryption module 1320 if the request isencrypted. Encryption/decryption module 1320 decrypts the request. Also,in some embodiments, communication module 1310 sends the payment requestto a function processing system to determine an approval or denial of atransaction if the UIS verification module 1340 determines the UIScorresponds to the primary account UIS. Similarly, communication module1310 can send the reward code to a rewards processing system, in someembodiments, where a determination of the type and amount of rewardassociated with the reward code.

In accordance with some embodiments, the incoming authorization ortransaction request includes an encrypted string of characters. Theauthorization request can also include various types of information suchas a payment request amount, a primary account string, a useridentification string (UIS), transmission time and date, payment deviceexpiration date, processing code, and/or the like. The string ofencrypted characters can include a function selector, a reward code andother tokens. The authorization request can be parsed using parsingmodule 1330 in embodiments of verification system 220. For example,parsing module 1330 can use parsing logic to turn the authorizationrequest into various tokens such as primary account string, the MUIS,the UIS, the function selector, the reward code and/or the like that arecontained within the string of characters.

The UIS entered by the user, in some embodiments of the presentinvention, allows for the user to enter a reward code with the UIS thusgenerating a modified UIS (MUIS). In some cases, traditional parsinglogic is used to extract, in part, the MUIS not knowing that it containsspecial reward code information. The MUIS can then be passed through anadditional set of parsing logic where the UIS and the reward code areseparated. In some embodiments, parsing the reward code and UIS is notnecessary. For example, the MUIS can be directly compared to a presetUIS that includes the UIS and reward code stored in a UIS database. Insome embodiments, the UIS database is encrypted.

UIS verification module 1340 validates a user, in some embodiments, bycomparing a primary account UIS stored in a UIS database and associatedwith the primary account string with the UIS received in the encryptedstring of characters. If the UIS stored in the UIS database does notmatch the UIS received, then the transaction is denied. If there is amatch, then function determination module 1350 can be used to determinethe desired function if a function indicator is present in the string ofcharacters. If a function indicator is not present, then a set ofpre-determined rules (e.g., associated with the individual useroperation vehicle or a default across all user operation vehicles) couldbe followed for processing the transaction request. In some embodiments,the UIS is the function indicator with a unique UIS associated with eachpayment function linked to the user operation vehicle. Using either thedetermined function, UIS, or the pre-determined processing rules,function routing module 1360 routes the transaction to the appropriatepayment processing system.

In some embodiments, when a reward code is present in the string ofcharacters, reward verification module 1370 determines if the rewardcode is valid and what action is associated with the reward code. Forexample, the action could apply a certain percentage discount (e.g., tenpercent off), give a certain amount off (e.g., five dollars off), freeshipping, generate a reward credit, and the like. In some embodiments,determining the action associated with the reward code includestransmitting the reward code to a reward code verification module(reward code verifier) that is external to verification system 220(e.g., the module is managed by a particular store or bank). Theexternal reward code verification module determines the amount andvalue, if any, of the benefit and what action should be taken. Thisaction is then transferred back to verification system 220, in someembodiments, and the benefit is applied.

Once the action or benefit is implemented, the transaction can beprocessed through the appropriate payment processing system. In someembodiments, the payment processing system includes a transaction typeauthorizer which can approve or decline the authorization request.

FIG. 14 is a block diagram illustrating various components that may be apart of a real-time payment processing network 1400 in accordance withsome embodiments of the present invention. Embodiments of the real-timepayment processing network 1400 use various methods for processing areward code which is presented by the user. The reward code may bepresented in conjunction with a user's UIS (e.g., in a MUIS) to addfunctionality to the UIS when the user purchases goods or services at aPOI. According to some embodiments, the user operation vehicle (e.g.,card) can be associated with one or more accrued value or paymentaccounts (e.g., prepaid, debit, credit, etc.) and is presented at a POIuser interface 1410 by user 1405.

The user's primary account number is received at a POI device throughPOI user interface 1410 in some embodiments of the present invention.For example, depending on the type of user operation vehicle being used,POI user interface 1410 can be a card reader, a magnetic strip reader, afingerprint reader, manual entry key pad, a computer keyboard, voicerecognition software, any biometric identifying device, and/or the like.A primary account number could be read directly from the user operationvehicle (e.g., when reading a card) or retrieved from a database. Insome cases, a primary account number could be generated through uniquecharacteristics of the user operation vehicle (e.g., applying aprocessing algorithm to a fingerprint). According to some embodiments,the primary account number can be associated with a single account orwith one or more accrued value, reward, prepaid, credit, debit, and/orother payment accounts.

POI user interface 1410, in some embodiments, is in communication with aPOI application 1110 which can be used for managing one or moreperipheral devices such as a touch screen for order entry, printers,electronic cash registers, and/or the like. In some embodiments, POIapplication 1110 is a software application running on a computer throughthe Internet.

User 1405 can be prompted to enter a UIS that can be used to verify theidentity of the user and/or select a payment function if the useroperation vehicle is a multi-function user operation vehicle. User 1405enters a UIS along with additional reward numbers. Once the primaryaccount, UIS, and additional reward numbers are received along with anyother information required by POI application 1110, POI application 1110sends the primary account number, UIS, and reward numbers todecryption/encryption module 1250 where the information is encrypted togenerate an encrypted input string of numbers before being transferredover network 1115 to a transaction processing system (an authorizationrequest processing network). This information is typically partiallyencrypted, although in some embodiments it may be entirely encrypted.For example, in some embodiments, the UIS (or MUIS) would be encrypted,the account number would not be encrypted, and other pieces may or maynot be encrypted depending on the technology, administrator preferences,and/or protocols set in place.

The encrypted input string of numbers from the POI device is receivedand then decrypted using decryption/encryption module 1420. In theembodiments illustrated in FIG. 14, after the string of numbers isdecrypted (e.g., by decryptor 1420) the result is communicated to UISparsing and authentication module 1425. Module 1425 parses the decryptedinput string into the various tokens and verifies user 1405 isauthorized to use the user operation vehicle by verifying the UISprovided corresponds with the primary account number. A determination ismade as to whether input string contains reward numbers using rewarddetermination logic.

If a determination is made that reward numbers or code exist in theinput string, the reward numbers are passed to reward verificationmodule (reward verifier) 1430. Module 1430 uses the information providedby UIS parsing and authentication module 1425 to determine the rewardand/or action associated with the reward numbers in the input string.Reward application module 1435, in accordance with some embodiments, isconfigured to apply the reward, or take the reward action. For example,if the reward was an immediate ten percent discount, then the discountwould be applied immediately to the transaction.

Once the application of the reward is complete, payment authorizationmodule (function deduction authorizer) 1440 determines the appropriatepayment processing network, transmits a request for payment to thedetermined payment processing network, and receives a paymentauthorization response (e.g., authorization, denial, partial denialindicating the amount that would be allowed, etc.). Determining theappropriate payment processing network can occur in a variety of waysdepending on the embodiments in use. For example, in some embodiments, afunction selector, that was included in the string of numbers, can besupplied to payment authorization module 1440 by UIS parsing andauthentication module 1425. As another example, a unique UIS can besupplied to payment authorization module 1440 by UIS parsing andauthentication module 1425. The unique UIS can then be used to determinewhich function associated with the primary account should be charged. Inother embodiments, the primary account number includes routinginformation for payment processing that can be used by paymentauthorization module 1440 for routing the payment request. When therequest to fund the transaction is approved or denied, the result ispassed to the POI device.

FIG. 15 is a block diagram illustrating various components that may be apart of a batch payment processing network 1500 in accordance with someembodiments of the present invention. According to the embodimentsillustrated in FIG. 15, batch processing of payment requests occur inmuch the same way as real-time payment processing requests up untilpayment authorization module 1440. At payment authorization module 1440,various pieces of transaction information are received from the UISparsing and authentication module 1425. Examples of the transactioninformation include, but are not limited to, the primary account number,UIS, reward code, function selection, payment request amount, merchantinformation, and/or the like.

As discussed above, some embodiments of the present invention include adelayed payment option that allows a customer who wants to process thetransaction today but have the funds withdrawn from available accounts afew days later, set up recurring payments, have installment payments,and/or the like. Batch payment processing network 1500 describes someways these transactions can be processed in accordance with variousembodiments of the present invention.

Unlike the real-time payment processing network 1400, some piece of thetransactional information (e.g., the application of the reward code) isnot processed immediately but is stored in payment database 1545.According to various embodiments, the information could be sorted andstored based on one or more features of the requested transactions.Examples of features of the requested transactions include, but are notlimited to, payment type, reward code present, merchant, authorizingfinancial institution, payment amount, and the like. Then, when atriggering event occurs, reward verification module 1430 pulls theinformation from payment database 1545 and determines if a reward codeis present and what reward action, if any, should be taken. Examples oftriggering events include, but are not limited to, timed intervals(e.g., every 5 seconds, every two minutes, every fifteenth day of themonth, every two weeks, etc.), request from authorizing institutions,request from a specific payment network (e.g., credit network), aspecified number of requests have been stored, and/or the like. Thereward information can then be passed onto reward application module1435 where the reward action is applied and the transaction requests arepassed onto payment authorization module 1440.

FIG. 16 is a block diagram illustrating various components that may be apart of a UIS parsing and authentication module 1425 in accordance withsome embodiments of the present invention. According to someembodiments, an incoming authorization or transaction request thatincludes a string of characters can be received from a POI device.Module 1425 can parse the string into the various tokens, verify whethera user is authorized to use the user operation vehicle, and determinewhether an input string of characters contains a reward code. Accordingto the embodiments shown in FIG. 16, UIS parsing and authenticationmodule 1425 can include the following components: UIS/Primary accountidentification module 1645, reward code parsing module 1650, functionidentification module 1655, and account database 1660.

The transaction request, including the input string of characters, isreceived at UIS/Primary account identification module 1645. According tosome embodiments of the present invention, the transaction request caninclude a payment request amount, primary account string, a useridentification string (UIS), input string of characters, a functionselector, a merchant identification code, a reward code, and/or otherpieces of information. Module 1645 identifies the UIS and the primaryaccount identification code in the transaction request. Theidentification of the UIS and primary account identification code can bedone in many ways. For example, the transaction request can have a fixedstructure (e.g., first sixteen characters are always the primary accountidentification code immediately followed by four characters which arethe UIS entered by the user) allowing the parts to be easily identified.In some cases, the transaction request can include identificationsub-strings which identify the organization, type of information, and/orthe length of each of the sub-strings.

Reward code parsing module 1650 determines if any reward code is presentin the input string of characters associated with the transactionrequest. The identification of the reward code can be done using manymethods. For example, in some embodiments, the string of characters hasa fixed structure (e.g., first eight characters are a reward code)allowing the parts to be easily identified. In some embodiments, thestring of characters include identification sub-strings which identifythe organization, type of information, and the length of each of thesub-strings. According to some embodiments, reward code parsing module1650 can also identify customer and merchant information stored withinthe string of characters. This feature can be useful in embodimentswhere the same reward code can result in a different reward action fordifferent merchants and/or customers.

Function identification module 1655, in some embodiments of the presentinvention, determines which payment function account associated with theuser operation vehicle should be used if more than one account isavailable. This can be done in a variety of ways. For example, the UISidentified by UIS/Primary account identification module 1645 can be usedto determine the payment function and account to be used in completingthe authorization request. In some embodiments, a function selector canbe provided by the user.

According to some embodiments, function identification module 1655 is incommunication with account database 1660. Using the unique UIS, thefunction selector, or some other means of account identification, module1655 is able to look up account information in database 1660 and verifythat the user is authorized to request a transaction.

FIG. 17 is a block diagram illustrating various components that may be apart of reward verification module 1430 in accordance with someembodiments of the present invention. According to some embodiments ofthe present invention, if a determination is made that reward numbersexist in the input string, the reward numbers are passed to rewardverification module 1430. Module 1430 uses the information provided byUIS parsing and authentication module 1425 to determine the rewardand/or action associated with the reward numbers in the input string.

In some embodiments, reward verification module 1430 receivesinformation about the transaction request. For example, rewardverification module 1430 can receive the entire account string and/orvarious tokens from the string of characters (e.g., reward string,primary account, merchant code, etc.). Once the information is received,customer/merchant identification module 1735 and reward stringidentification module 1730 can be used to determine the appropriatereward action in accordance with various embodiments of the presentinvention.

Reward string identification module 1730 identifies the reward string orcode from the information received. Then, according to some embodiments,determines if the reward string is customer and/or merchant specific. Ifso, then reward string identification module 1730 requests thatcustomer/merchant identification module 1735 verify that the rewardstring is valid with the current customer and/or merchant. In accordancewith some embodiments of the present invention, this type of informationcan be encoded in the reward code. In some embodiments, little (or no)information is encoded in the reward code and a lookup must be performedusing reward database 1440 to determine the appropriate reward actionand requirements.

For example, a particular reward code may provide for a twenty dollardiscount on a purchase of seventy-five dollars or more only at MerchantA. Consequently, when reward string identification module 1730determines that this code is only valid at Merchant A, a request can bemade for merchant identification through customer/merchantidentification module 1735. Once the request is received, then module1735 determines whether the user is making the purchase specificallyfrom Merchant A and returns the merchant identification to module 1730.

FIG. 18 is a flowchart illustrating operations 1800 for processing atransaction from a POI device (e.g., a point of sale device) inaccordance with some embodiments of the present invention. According tothe embodiments of the present invention illustrated in FIG. 18, aninput string is received from a POI device during receiving operation1810. The input string may include one or more of a reward code, delayedpayment option, a function selector, and/or a UIS. The POI device can beany mechanism, from a card reader to a personal computer, that can beused to facilitate the completion of a transaction with a merchant.According to some embodiments, once the input string is received it mayor may not be encrypted before being transferred to the processingnetwork. If the input string is encrypted, then a decryption can occurduring decryption operation 1820 in accordance with some embodiments ofthe present invention before further processing of the input string.

During verification operation 1830, the UIS and account information areverified and a determination is made if the user is authorized tocomplete the transaction. For example, in some embodiments, a securedatabase is accessed which stores account identification information(e.g., account numbers) with one or more UIS's. The UIS included in thereceived input string is compared with the account identificationinformation found in the input string. The secure database can alsoinclude, in some embodiments, routing and processing information foreach account. If a decision is made that the user is not authorized,then the processing of the transaction ends.

Once verification operation 1830 is complete, determination operation1840 determines if the received input string includes a reward number orcode. If a reward code is present, then the code may be stored for laterdetermination of the reward action. If a determination is made that noreward code is present, then no recording action is taken.

Once the account information and UIS are verified and a determination ismade that the user is authorized, the processing operations branch tovalid reward number decision operation 1850. According to someembodiments, valid reward number decision operation 1850 determines ifthe reward number in the input string is valid. If no reward number ispresent or a determination is made that the reward code is not valid,then the operations branch to funds verification operation 1870. If adetermination is made that a valid reward number exists, then the rewardaction is determined and the processing operations branch to rewardapplication operation 1860 where the reward action is applied. In someembodiments, decision operation 1850 determines if the reward number isvalid by decoding the reward string, accessing a database and looking uppart or all of the reward string, and/or using other methods.

Once the reward application operation 1860 finishes applying the rewardaction (e.g., five percent discount, ten dollars off, etc.), thetransaction processing operations branch to funds verification operation1870. Funds verification operation 1870 verifies the funds are availablein the account (e.g., using a payment processing system). If the fundsare available, then authorization operation 1880 completes thetransaction between the POI device and the payment function. Ifsufficient funds are not available, or the transaction request is deniedfor any other reason (e.g., daily limit exceeded), then authorizationoperation 1880 terminates the transaction request and notifies the POIdevice that the transaction cannot be completed. In some embodiments,funds may be obtained from different accounts, according to apredetermined order, in order to complete the transaction. Thetransaction may be partially approved using only the funds available inthe account in some embodiments. If the transaction is only partiallyapproved, the user may be notified that additional funds are needed forthe transaction to be completed.

FIG. 19 is a block diagram illustrating various components that may be apart of an accumulated value function processing system (accumulatedvalue function processor) 1900 in accordance with some embodiments ofthe present invention. In accordance with the embodiments illustrated inFIG. 19, a user 1905 makes a purchase at a merchant using an accumulatedvalue function associated with a user operation vehicle. Merchantprocessors 1910 (e.g., processors within a POI) generate anauthorization request and transmit the authorization request toprocessing and routing network 1915. Processing and routing network 1915can include, for example, network 1115, verification system 220, andprocessing systems 1130-1145.

A determination is made within the processing and routing network toroute the authorization request to accumulated value authorizer 1920 forprocessing. Once the authorization request is received, accumulatedvalue authorizer 1920 queries account and balances database 1925 todetermine the available balance for the accumulated value function. Theauthorization request can also be logged in authorization log 1930 alongwith the action taken by accrued value authorizer 1920.

If the balance of the account is determined to have insufficient accruedvalue to cover the purchase, the accumulated value authorizer 1920 candeny the transaction, partially approve the transaction, or apply thebalance and return a modified authorization request to the processingand routing network 1915 where another function associated with the useroperation vehicle can be charged, or the balance can be returned to theprocessing and routing network 1915 where a decision is made on how toprocess the charge (e.g., submit part to the accumulated value functionand part to another function).

If the accumulated value authorizer 1920 determines there is asufficient balance (e.g., in rewards, cash equivalents, cash values,etc.) associated with the accumulated value function account, then theauthorization request can be submitted to batch accumulated valueprocessing module 1935. The batch accumulated value processing module1935 updates or refreshes the account and balance file associated withthe user once the processing occurs. The result (e.g., successful,failed, try again, etc.) can be communicated to the accrued valueauthorizer which communicates the result to the merchant processors1910.

In addition to processing transaction using accumulated value functions,the accumulated value function processing system 1900 also creditsaccrued value to the accumulated value function account. For example,when user 1905 makes a purchase from a particular merchant and/or for anitem within a particular category (e.g., food, gas, automotive, etc.) anaccrued value can be generated. The purchase information (e.g., amount,identification, etc.) is transmitted to the accumulated value authorizer1920. The accumulated value authorizer 1920 makes a determination usingaccumulation logic of the amount that the accumulated value accountshould be credited. This information is passed to the batch accumulatedvalue processing module 1935 where the user operation vehicleinformation is verified using the user operation vehicle database 1945and the accrued value amount is updated.

In some embodiments, the user can access account history, thereconciliation process, the settlement process, statements, and otherinformation through a remote interface in communication with theaccumulated value function processing system 1900. Examples of a remoteinterface include, but are not limited to a webpage, Java™ application,a downloadable computer program, cell phone applet, dedicated terminal,and/or the like.

FIG. 20 is an example of a promotional flyer 2000 that includes rewardcodes that may be used in some embodiments of the present invention.While FIG. 20 illustrates a promotional flyer 2000 that includes rewardcodes, the reward codes can come from any number of places. For example,according to some embodiments, reward codes can be found on foodpackaging (e.g., under a bottle cap, the back of a box, etc.),television advertisements, promotional flyers, coupon book, newspaperadvertisements, automated telephone calls (e.g., from outbound voiceresponse units), promotional emails, short messaging system (SMS)message, and/or the like. In some embodiments, the promotional flyerscan be created with paper, plastic, or other material. The promotionalcodes can take any form from solely numerical strings to alphanumericstrings.

FIG. 20 shows a communication region 2005 where text, graphics,drawings, pictures, and/or the like can be used to convey informationabout the promotion to the viewer. In the embodiments shown in FIG. 20,below communication region 2005 are three reward regions 2010 a-2010 c.However, in other embodiments, the place of the reward regions and thenumber of coupons can vary.

Within each reward region is a description of the type of reward (2015a-2015 c). However, in other embodiments, no description may be presentand the reward may remain unknown to the user until the user enters thereward code during a transaction. In addition to a description, thereward regions include at least one reward code (2020 a-2020 c) andpossibly an expiration date (2025 a and 2025 c) after which the rewardcodes will no longer be valid. In the embodiments shown, the rewardcodes are completely numerical. However, according to some embodiments,the reward codes can be of any length and can, in some cases, includeletters.

In some embodiments, the reward codes may be presented to users throughthe POI device or a screen attached to the POI or POI system. Accordingto some embodiments, the POI can download various advertisements duringthe day (e.g., at night, periodically throughout the day, once a day, ona predetermined schedule, etc.). Associated with each advertisement isan advertising code. The system will send advertising codes to the POIthat will trigger these advertising components to be shown on the POIdevice itself or a device in communication with the system. Oneadvantage of downloading the advertisements and allowing the system tosend advertising codes to trigger the advertisements is the ability todisplay the advertisements quicker since they have been previouslydownloaded.

Exemplary Computer System Overview

Some embodiments of the present invention include various steps, some ofwhich may be performed by hardware components or may be embodied inmachine-executable instructions. These machine-executable instructionsmay be used to cause a general-purpose or special-purpose processorprogrammed with the instructions to perform the steps. Alternatively,the steps may be performed by a combination of hardware, software,and/or firmware. In addition, some embodiments of the present inventionmay be performed or implemented, at least in part (e.g., one or moremodules), on one or more computer systems, mainframes (e.g., IBMmainframes such as the IMB zSeries, Unisys ClearPath Mainframes, HPIntegrity NonStop servers, NEC Express series, and others), orclient-server type systems. In addition, specific hardware aspects ofembodiments of the present invention may incorporate one or more ofthese system, or portions thereof.

As such, FIG. 21 is an example of a computer system 2100 with whichembodiments of the present invention may be utilized. According to thepresent example, the computer system includes a bus 2101, at least oneprocessor 2102, at least one communication port 2103, a main memory2104, a removable storage media 2105, a read only memory 2106, and amass storage 2107. In some embodiments, an encryption/decryptionhardware component (not shown) may be present or associated with thecomputer system 2100. Examples of commercially available components arecurrently available from ATALLA, THALES, and IBM. In some embodimentsone or more nCipher host security modules can be used.

Processor(s) 2102 can be any known processor, such as, but not limitedto, an Intel® Itanium® or Itanium 2® processor(s), or AMD® Opteron® orAthlon MP® processor(s), or Motorola® lines of processors. Communicationport(s) 2103 can be any of an RS-232 port for use with a modem baseddialup connection, a 10/100 Ethernet port, or a Gigabit port usingcopper or fiber. Communication port(s) 2103 may be chosen depending on anetwork such a Local Area Network (LAN), Wide Area Network (WAN), or anynetwork to which the computer system 2100 connects.

Main memory 2104 can be Random Access Memory (RAM), or any other dynamicstorage device(s) commonly known in the art. Read only memory 2106 canbe any static storage device(s) such as Programmable Read Only Memory(PROM) chips for storing static information such as instructions forprocessor 2102.

Mass storage 2107 can be used to store information and instructions. Forexample, hard disks such as the Adaptec® family of SCSI drives, anoptical disc, an array of disks such as RAID, such as the Adaptec familyof RAID drives, or any other mass storage devices may be used.

Bus 2101 communicatively couples processor(s) 2102 with the othermemory, storage and communication blocks. Bus 2101 can be a PCI/PCI-X orSCSI based system bus depending on the storage devices used.

Removable storage media 2105 can be any kind of external hard-drives,floppy drives, flash drives, IOMEGA® Zip Drives, Compact Disc-Read OnlyMemory (CD-ROM), Compact Disc-Re-Writable (CD-RW), Digital VideoDisk-Read Only Memory (DVD-ROM).

The components described above are meant to exemplify some types ofpossibilities. In no way should the aforementioned examples limit thescope of the invention, as they are only exemplary embodiments.

In conclusion, embodiments of the present invention provide novelsystems, methods and arrangements for the generation of useridentification strings used with multi-function operation vehicles andto the addition of functionality to a user identification string for useat a POI. While detailed descriptions of one or more embodiments of theinvention have been given above, various alternatives, modifications,and equivalents will be apparent to those skilled in the art withoutvarying from the spirit of the invention. Therefore, the abovedescription should not be taken as limiting the scope of the invention,which is defined by the appended claims.

Various modifications and additions can be made to the exemplaryembodiments discussed without departing from the scope of the presentinvention. For example, while the embodiments described above refer toparticular features, the scope of this invention also includesembodiments having different combinations of features and embodimentsthat do not include all of the described features. Accordingly, thescope of the present invention is intended to embrace all suchalternatives, modifications, and variations as fall within the scope ofthe claims, together with all equivalents thereof.

1. An authorization request processing network comprising: a point ofinteraction (POI) device to generate an authorization request thatincludes 1) a vehicle code identifying a user operation vehicle and 2) amodified user identification string (MUIS) that includes a user code anda user identification string (UIS) provided by a user at the POI device,wherein the POI device includes an encryptor to encrypt at least part ofthe authorization request; a verifier in communication with the POIdevice through a communication network, and wherein the verifierincludes: a decryptor to decrypt the authorization request generated bythe POI device; and a parsing module to parse the authorization requestinto a function deduction request, the vehicle code, and the MUIS; andwherein the verifier verifies the UIS corresponds to a primary accountUIS associated with the user operation vehicle; a user code processingsystem to determine an action associated with the user code and toimplement the action; one or more function processors in communicationwith the verifier, wherein the verifier requests, from the one or morefunction processors, an approval or a denial of the authorizationrequest originating from the POI device if the verifier determines theUIS corresponds to the primary account UIS.
 2. The authorization requestprocessing network of claim 1, wherein the user code includes one ormore of a reward code, a function indicator, or an account activationcode.
 3. The authorization request processing network of claim 1,wherein the user code includes a savings indicator to cause an amount ofthe authorization request to be rounded to an indicated dollar incrementamount and cause the difference between the amount of the authorizationrequest and the indicated dollar increment dollar amount to be depositedinto a function account.
 4. The authorization request processing networkof claim 3, wherein the indicated dollar increment amount is one dollar,five dollars, or ten dollars.
 5. The authorization request processingnetwork of claim 1, wherein the user code processing system is a rewardcode processing system.
 6. The authorization request processing networkof claim 5, wherein the user code includes a reward code and the POIdevice further comprises a POI application to access the reward codeprocessing system and process the reward code before transmitting theauthorization request to the verifier.
 7. The authorization requestprocessing network of claim 1, wherein the verifier further comprises: afunction determination module to determine a payment function associatedwith the user operation vehicle by a payment function indicator; and aswitch to route the request for the approval or the denial of thetransaction to the determined payment function of the one or morefunction processors.
 8. The authorization request processing network ofclaim 1, wherein the POI device is a point of sale device.
 9. Theauthorization request processing network of claim 1, wherein the POIdevice is a computer integrated system.
 10. The authorization requestprocessing network of claim 1, wherein the POI device includes acomputer connected to the internet or a telephone payment system. 11.The authorization request processing network of claim 1, wherein thedecryptor includes one or more nCipher host security modules.
 12. Asystem for processing authorization requests originating from a point ofinteraction (POI) device, the system comprising: a communication devicein communication with the POI device; a processor in communication withthe communication device and a memory, wherein when an authorizationrequest is received at the communication device from the POI device, theprocessor processes the authorization request, and wherein theauthorization request includes a modified user identification string(MUIS) entered by the user at the POI device and the MUIS contains atleast a user identification string (UIS) and a user code; and theprocessor also parses the MUIS into the UIS and the user code,determines an action associated with the user code, applies the actionassociated with the user code, and routes the authorization request to afunction processor for payment authorization.
 13. The system of claim12, wherein the authorization request is at least partially encryptedand the processor routes the authorization to a decryptor to bedecrypted.
 14. The system of claim 13, wherein the decryptor includesonly hardware components.
 15. The system of claim 13, wherein thedecryptor includes one or more nCipher host security modules.
 16. Thesystem of claim 12, wherein the user code includes a function indicatorand the processor also: determines a payment function based on thefunction indicator that is included in the user code; and determines thefunction processor that is associated with the payment function andwherein the function processor is used in processing the authorizationrequest.
 17. The system of claim 12, wherein the user code includes areward code and to determine the action associated with the reward code,the processor also: transmits the reward code to a reward code verifier,wherein the reward code verifier determines if the actions include oneor more reward benefits; and receives the one or more reward benefitsfrom the reward code verifier.
 18. The system of claim 17, wherein todetermine the one or more reward benefits associated with the rewardcode, the processor also: accesses a reward database that has storedthereon a plurality of stored reward codes each associated with the oneor more reward benefits; locates the stored reward code in the rewarddatabase that corresponds to the reward code provided within the usercode entered at the POI device; and determines, from the stored rewardcode, the one or more reward benefits associated with the reward code.19. The system of claim 12, wherein the user code includes an accountactivation code and to determine the action associated with the accountactivation code, the processor also: determines an inactive accountassociated with the account activation code; and activates the inactiveaccount.
 20. A function deduction verification system comprising: areceiver to receive, from a point of interaction (POI) device through acommunication network, a string of characters that includes a functiondeduction request, a primary account string, and an encrypted modifieduser identification string (MUIS) that includes a user identificationstring (UIS) and a reward code entered by a user in response to arequest by the POI device to enter the UIS associated with a useroperation vehicle presented to the POI device; a decryptor to decryptthe string of characters including at least the encrypted MUIS; aparsing module configured to parse the string of characters receivedfrom the decryptor into the function deduction request, the primaryaccount string, the UIS, and the reward code; a verifier to receive theprimary account string and the UIS from the parsing module, and whereinthe verifier verifies the UIS corresponds to a primary account UIS; acommunications module to send the function deduction request to afunction processor for approval or denial if the verifier determines theUIS corresponds to the primary account UIS, and wherein thecommunication module sends the reward code to a rewards processor todetermine a type and amount of reward associated with the reward code;and a function deduction authorizer to apply credit for the reward andcommunicate the approval or denial of the function deduction request tothe POI device.
 21. The function deduction verification system of claim20, wherein the string of characters also includes a function indicatorand the function deduction verification system further comprises: afunction determination module to determine a function associated withthe primary account indicated by the function indicator; and a switch toroute the payment request to the function processor corresponding to thedetermined function.
 22. The function deduction verification system ofclaim 20, wherein the function processor and the rewards processor areintegrated into a single system.
 23. The function deduction verificationsystem of claim 20, wherein the function processor includes a rewardsfunction processing module, a debit function processing module, and acredit function processing module.
 24. The function deductionverification system of claim 20, further comprising a merchantidentification module capable of determining if the string of charactersincludes a merchant identification code.
 25. The function deductionverification system of claim 24, wherein the merchant identificationmodule is further operable to determine if the reward code applies onlyto one or more specific merchants and wherein the merchantidentification module is able to determine the type and amount of rewardallowed by the reward code with the merchant identified by the merchantidentification code.
 26. The function deduction verification system ofclaim 20, wherein the communication network includes at least one of adedicated communication channel, a local area network (LAN), a publicswitched telephone network (PSTN), a broadband network, an internetservice provider (ISP) network, or a voice network.
 27. The functiondeduction verification system of claim 20, wherein the decryptorincludes one or more nCipher host security modules.
 28. Acomputer-implemented method comprising: receiving an authorizationrequest that is at least partially encrypted and includes 1) a vehiclecode identifying a user operation vehicle supplied by a user at a pointof interaction (POI) device and 2) a modified user identification string(MUIS) entered by the user at the POI device, wherein the MUIS containsat least a user identification string (UIS) and a user code; utilizing adecryptor to decrypt any part of the authorization request that isencrypted; parsing, using one or more parsing modules, the MUIS into theUIS and the user code; validating the user, using a verifier, bycomparing a primary account UIS stored in a UIS database with the UISreceived in the authorization request; determining an action associatedwith the user code; and implementing the action associated with the usercode and routing the authorization request to a function processor forpayment authorization.
 29. The computer-implemented method of claim 28,further comprising: transmitting the vehicle code to the verifier; andselecting the primary account UIS that is associated with the useroperation vehicle identified by the vehicle code.
 30. Thecomputer-implemented method of claim 28, wherein the user code includesa reward code.
 31. The computer-implemented method of claim 30, whereinthe action associated with the reward code is a percentage discount on atotal price, a percentage discount on a particular item, multiple rewardpoints, a dollar amount discount on a total price, buy one get one freeof a particular item, or a free delivery of one or more items.
 32. Thecomputer-implemented method of claim 28, wherein the MUIS also includesa function indicator indicating a selected function of a plurality offunctions linked to a user operation vehicle, the method furthercomprising: determining the selected function based on the functionindicator that is included in the MUIS; selecting the function processorthat is associated with the selected function; and utilizing a switch toroute the authorization request to the function processor for paymentauthorization.
 33. The computer-implemented method of claim 32, whereinpayment authorization comprises: generating, by the function processor,a settlement file indicating approval or denial of the authorizationrequest; transferring the settlement file to a settlement controller forsubmission to a merchant settlement controller associated with the POIdevice.
 34. The computer-implemented method of claim 32, wherein a firstset of characters as the function indicator indicates the selection of adebit payment function, a second set of characters as the functionindicator indicates the selection of a credit payment function, a thirdset of characters as the function indicator indicates the selection ofan accumulated value payment function, and a fourth set of characters asthe function indicator indicates the selection of a prepaid paymentfunction.
 35. The computer-implemented method of claim 34, wherein thefirst set of characters is the number one, the second set of charactersis the number two, the third set of characters is the number three, andthe fourth set of characters is the number four.
 36. Thecomputer-implemented method of claim 32, wherein the action associatedwith the user code provides a predetermined payment arrangement thatdiffers from the standard terms of the selected function.
 37. Thecomputer-implemented method of claim 36, wherein the predeterminedpayment arrangement is thirty days same as cash, ninety days same ascash, or one hundred eighty days same as cash.
 38. Thecomputer-implemented method of claim 28, wherein determining an actionassociated with the user code comprises parsing the user code into oneor more tokens.
 39. The computer-implemented method of claim 28, whereinthe user code is a reward code and determining an action associated withthe reward code comprises: transmitting the reward code to a reward codeverifier, wherein the reward code verifier determines or authorizes oneor more reward benefits associated with the reward code; and receivingfrom the reward code verifier an indication of the one or more rewardbenefits that were determined or authorized.
 40. Thecomputer-implemented method of claim 39, wherein determining the one ormore reward benefits associated with the reward code comprises:accessing a reward database that has stored thereon a plurality ofstored reward codes each associated with one or more reward actions;locating a stored reward code in the reward database corresponding tothe reward code parsed from the MUIS; and determining, from the storedreward code, the one or more reward benefits associated with the rewardcode.
 41. The computer-implemented method of claim 39, wherein theauthorization request includes a merchant code associated with amerchant where the authorization request originated, wherein at leastone of the one or more benefits associated with the reward code can onlybe applied at a particular merchant or set of merchants, and whereindetermining the one or more reward benefits associated with the rewardcode comprises determining if each of the one or more reward benefitsassociated with the reward code can be applied to the merchant indicatedby the merchant code.
 42. The computer-implemented method of claim 28,wherein before determining and applying the action associated with theuser code, the method further comprises: storing the authorizationrequest in a batch processing database that includes one or moreadditional pending authorization requests; and monitoring for atriggering event before processing the authorization request and the oneor more additional pending authorization requests stored in the batchprocessing database.
 43. The computer-implemented method of claim 42,wherein the triggering event is a timed interval or a request from aprocessing system.
 44. The computer-implemented method of claim 28,wherein the user code includes an account activation code and the methodfurther comprises: validating the account activation code by accessingan activation code database that has stored thereon a plurality ofauthorized activation codes and comparing the activation code with theplurality of authorized activation codes; and activating one or morenon-activated accounts associated with the activation code if theactivation code matches one of the plurality of authorized activationcodes stored on the activation code database.
 45. Thecomputer-implemented method of claim 28, further comprising providingthe user code to the user through a flyer.
 46. The computer-implementedmethod of claim 28, further comprising providing the user code to theuser through a communication format selected from a short messagingsystem (SMS) message, an e-mail, or an outbound voice response unitmessage.
 47. The computer-implemented method of claim 28, wherein theuser code includes a savings indicator, wherein the method furthercomprises: rounding a function deduction amount associated with theauthorization request to an indicated dollar increment amount; amendingthe authorization request to indicate the rounding of the functiondeduction amount for processing by the function processor; computing thedifference between the amount of the authorization request and theindicated dollar increment amount; and depositing the difference into afunction account.
 48. The computer-implemented method of claim 47,wherein the indicated dollar increment amount is one dollar, fivedollars, or ten dollars.
 49. A computer-readable storage mediumcontaining a set of instructions capable of causing one or moreprocessors to: receive, from a point of interaction (POI) device, anauthorization request that includes 1) a vehicle code identifying a useroperation vehicle and 2) a modified user identification string (MUIS)that includes a user identification string (U IS) and a user codeentered as a single input string by a user at the POI device; determinean action associated with the user code; and send an approval or denialof the authorization request to the POI device after the action has beenapplied.
 50. The computer-readable storage medium of claim 49, whereinthe set of instructions are further capable of causing one or moreprocessors to: verify the UIS received from the POI device matches astored UIS associated with a primary account identified with the vehiclecode; and deny the authorization request if the UIS is not successfullyverified.
 51. The computer-readable storage medium of claim 49, whereinthe set of instructions are further capable of causing one or moreprocessors to: determine if the authorization request includes afunction indicator indicating a selected function type; and process theauthorization request by sending the authorization request to a functionauthorizer able to process the selected function type by approving ordeclining the authorization request based on pre-set processing rules.52. The computer-readable storage medium of claim 49, wherein the set ofinstructions are further capable of causing one or more processors to:determine if the authorization request includes a merchantidentification code; determine if the user code requires successfulmerchant identification before application of the action associated withthe user code; and determine if the merchant identification codeidentifies a merchant to which the user code is applicable.
 53. Thecomputer-readable storage medium of claim 49, wherein the user code is areward code and wherein the set of instructions are further able todetermine a reward action associated with the reward code by causing oneor more processors to: transmit the reward code to a reward codeverifier, wherein the reward code verifier determines the amount andvalue of the reward action; and receive from the reward code verifierthe determined amount and value of the benefit.
 54. A system comprising:a receiving means for receiving an authorization request that includes amodified user identification string (MUIS) entered by a user at a pointof interaction (POI) device, wherein the MUIS contains at least a useridentification string (UIS) and a user code; an action determinationmeans for determining an action associated with the user code; an actionimplementation means for implementing the action associated with theuser code; and a routing means for routing the authorization request toa function processor for payment authorization.
 55. The system of claim54, wherein the authorization request further comprises a vehicle codeidentifying a user operation vehicle supplied by the user at the POI.56. The system of claim 54, further comprising a parsing means forparsing the MUIS into the UIS and the user code.
 57. The system of claim54, further comprising a verification means for validating the user bycomparing a primary account UIS stored in a UIS database with the UISreceived in the authorization request.
 58. The system of claim 54,wherein the authorization request is at least partially encrypted andthe system further comprises a decryption means to decrypt any part ofthe authorization request that is encrypted.
 59. The system of claim 58,wherein the decryption means includes one or more nCipher host securitymodules.
 60. The system of claim 54, wherein the user code includes areward code.
 61. The system of claim 60, wherein the action associatedwith the reward code is a percentage discount on a total price, apercentage discount on a particular item, multiple reward points, adollar amount discount on a total price, buy one get one free of aparticular item, or a free delivery of one or more items.
 62. The systemof claim 54, wherein the MUIS also includes a function indicatorindicating a selected function of a plurality of functions linked to auser operation vehicle, and wherein the routing means comprises: afunction indicator module for determining the selected function based onthe function indicator that is included in the MUIS; a functionselection module for selecting the function processor that is associatedwith the selected function; and a switch to route the authorizationrequest to the function processor for payment authorization.
 63. Thesystem of claim 54, wherein the function processor comprises: asettlement generation means for generating a settlement file indicatingapproval or denial of the authorization request; a transfer means fortransferring the settlement file to a settlement controller forsubmission to a merchant settlement controller associated with the POIdevice.
 64. The system of claim 62, wherein a first set of characters asthe function indicator indicates the selection of a debit paymentfunction, a second set of characters as the function indicator indicatesthe selection of a credit payment function, a third set of characters asthe function indicator indicates the selection of an accumulated valuepayment function, and a fourth set of characters as the functionindicator indicates the selection of a prepaid payment function.
 65. Thesystem of claim 62, wherein the action associated with the user codeprovides a payment arrangement that differs from a standard paymentterms of the selected function.
 66. The system of claim 65, whereinpayment arrangement is thirty days same as cash, ninety days same ascash, or one hundred eighty days same as cash.